在OOP中，我通过组合来构建代码，拥有大量的组件，我对此感到有些满意……所有的东西都放在盒子里：-(在纯FP中，什么是好的实践？
我想只是一个公开组件的Haskell模块有用吗？我应该玩数据类型吗？
例如：域内驱动设计：服务->存储库
- 服务A(服务X、服务Y、报告1、报告2、报告3(
- 服务B(服务A、服务C、服务Z、报告1、报告2、报告3(
- 服务C(服务A、服务B(
纯FP中的变化是，我不需要所有这些对象的实例化，我现在只需要一葡萄函数。。。心态完全不同。。。在我当前的代码中，所有的依赖项都是隐藏的，就像我在代码中到处使用"静态函数"一样，这对OOP测试来说非常糟糕。。。
我应该如何思考纯FP？
函数方法没有什么不同。简言之：
- 总是从最通用的抽象到最具体的抽象。它也适用于OOP，然而FP在这方面往往更明确。特别是，这意味着要将尚未部分应用的通用函数与使用这些函数的模块保持距离
- 组成。让你的"原始"函数远离合成是很好的，尤其是长函数。你们可能会把它当作#1的一个子项，尽管我会把它归类为自我重要的东西。(警告！像F#这样的一些语言强制新注释使用
(|>)运算符来编写函数。这不是你的方式：不要对它们求值，否则你就无法实现我在这里所说的：确保你的编写确实产生了新函数，并决定何时运行它( - 永远不要将IO或可变代码库(在Haskell的情况下为IO monad(与纯代码库混合
- 在适当的时候定义同义类型和新类型。将您的(Haskell(模块配置为仅导出这些位，您希望对消费者可用，而不是对整个模块可用(当然，当这样的模块相当简单时除外(
Alexander Granin开始写一本关于"功能设计和架构"的书，不幸的是，他没有完成那本书，但他完成了其中绝对值得一读的一部分：来源
你也可以在这里找到所有的细节：
- 从FP的角度进行架构建模、需求分析、子系统设计
- 领域建模中的嵌入式和外部DSL
- Monad作为具有效果的子系统
- 自由monad作为功能接口
- 其他类型的功能接口
- FP中的控制反转(使用自由一元eDSL(
- STM、IO Ref、MVar作为并发应用程序状态
- 镜片
- 子系统设计中的State、Reader、Writer、RWS、ST monad
- GUI和FP
- UML、SOLID、GRASP等主流技术和方法的适用性
- 与不纯子系统的相互作用
我希望有人给他时间来完成它：-(