Don已经给出了上面的大部分细节，但这里是我在Haskell中编写真正有状态程序(如系统守护进程)的一些观点。

In the end, you live in a monad transformer stack. At the bottom is IO. Above that, every major module (in the abstract sense, not the module-in-a-file sense) maps its necessary state into a layer in that stack. So if you have your database connection code hidden in a module, you write it all to be over a type MonadReader Connection m => ... -> m ... and then your database functions can always get their connection without functions from other modules having to be aware of its existence. You might end up with one layer carrying your database connection, another your configuration, a third your various semaphores and mvars for the resolution of parallelism and synchronization, another your log file handles, etc. Figure out your error handling first. The greatest weakness at the moment for Haskell in larger systems is the plethora of error handling methods, including lousy ones like Maybe (which is wrong because you can't return any information on what went wrong; always use Either instead of Maybe unless you really just mean missing values). Figure out how you're going to do it first, and set up adapters from the various error handling mechanisms your libraries and other code uses into your final one. This will save you a world of grief later.

增编(摘自评论;感谢Lii & liminalisht) - 更多关于将一个大程序分割成一个堆栈中的单子的不同方法的讨论:

Ben Kolera给出了这个主题的一个很好的实用介绍，Brian Hurt讨论了将单体动作提升到自定义单体的解决方案。George Wilson展示了如何使用mtl编写代码，以实现所需类型类的任何单子，而不是您的自定义单子类型。Carlo Hamalainen写了一些简短有用的笔记，总结了乔治的演讲。

我目前正在写一本名为《功能设计与架构》的书。它为您提供了一整套如何使用纯函数方法构建大型应用程序的技术。它描述了许多功能模式和思想，同时构建了一个类似scada的应用程序“仙女座”，用于从头开始控制宇宙飞船。我的主要语言是Haskell。这本书的封面是:

Approaches to architecture modelling using diagrams; Requirements analysis; Embedded DSL domain modelling; External DSL design and implementation; Monads as subsystems with effects; Free monads as functional interfaces; Arrowised eDSLs; Inversion of Control using Free monadic eDSLs; Software Transactional Memory; Lenses; State, Reader, Writer, RWS, ST monads; Impure state: IORef, MVar, STM; Multithreading and concurrent domain modelling; GUI; Applicability of mainstream techniques and approaches such as UML, SOLID, GRASP; Interaction with impure subsystems.

您可能熟悉本书的代码和“Andromeda”项目代码。

我希望在2017年底完成这本书。在此之前，你可以在这里阅读我的文章“函数式编程中的设计和架构”(Rus)。

更新

我在网上分享了我的书(前5章)。参见Reddit上的帖子

我的确是通过这本书第一次学习了结构化函数式编程。 它可能不是你想要的，但对于函数式编程的初学者来说，这可能是学习构造函数式程序的最好的第一步之一——与规模无关。在所有抽象层次上，设计都应该有清晰的结构安排。

函数式编程的技巧

http://www.cs.kent.ac.uk/people/staff/sjt/craft2e/

我发现Alejandro Serrano的论文“使用Haskell教授软件架构”(pdf)对思考Haskell中的大规模结构很有用。

Perhaps you have to go an step back and think of how to translate the description of the problem to a design in the first place. Since Haskell is so high level, it can capture the description of the problem in the form of data structures , the actions as procedures and the pure transformation as functions. Then you have a design. The development start when you compile this code and find concrete errors about missing fields, missing instances and missing monadic transformers in your code, because for example you perform a database Access from a library that need a certain state monad within an IO procedure. And voila, there is the program. The compiler feed your mental sketches and gives coherence to the design and the development.

以这种方式，您从一开始就受益于Haskell的帮助，并且编码是自然的。如果你脑子里想的是一个具体的普通问题，我不想做一些“功能性的”或“纯粹的”或足够一般的事情。我认为过度设计是IT领域最危险的事情。当问题是创建一个抽象一组相关问题的库时，情况就不同了。

Gabriel的博客文章可伸缩的程序架构可能值得一提。

Haskell设计模式与主流设计模式有一点不同 重要的方法: 常规架构:将多个组件组合在一起 类型A生成类型B的“网络”或“拓扑” Haskell体系结构:将几个A类型的组件组合在一起 生成一个相同类型a的新组件，在 其取代基部分的特征

It often strikes me that an apparently elegant architecture often tends to fall out of libraries that exhibit this nice sense of homogeneity, in a bottom-up sort of way. In Haskell this is especially apparent - patterns that would traditionally be considered "top-down architecture" tend to be captured in libraries like mvc, Netwire and Cloud Haskell. That is to say, I hope this answer will not be interpreted as an attempt replace any of the others in this thread, just that structural choices can and should ideally be abstracted away in libraries by domain experts. The real difficulty in building large systems, in my opinion, is evaluating these libraries on their architectural "goodness" versus all of your pragmatic concerns.

正如liminalisht在评论中提到的，分类设计模式是Gabriel关于这个主题的另一篇文章，以类似的方式。