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

函数式编程的技巧

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

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写了一些简短有用的笔记，总结了乔治的演讲。

我发现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关于这个主题的另一篇文章，以类似的方式。

用Haskell设计大型程序与用其他语言设计并没有什么不同。 在大范围内编程是关于将你的问题分解成可管理的部分，以及如何将它们组合在一起;实现语言不那么重要。

也就是说，在大型设计中，最好尝试并利用类型系统，以确保只能以正确的方式将各个部分组合在一起。这可能涉及到新类型或幻影类型，以使看起来具有相同类型的东西不同。

在重构代码时，纯粹性是一个很大的好处，所以尽量保持尽可能多的代码纯粹。纯代码很容易重构，因为它与程序的其他部分没有隐藏的交互。