函数式编程的后期架构
译者 | 刘雅梦
策划 | Tina
许多软件架构方法都是假设该架构在一开始时就进行了规划。但不幸的是，以这种方式规划的架构之后很难更改。函数式编程可以帮助我们实现松耦合，从而可以将预先的规划保持在最低限度，并可以在之后更改架构决策。
Michael Sperber 在 OOP 2023 Digital 大会上谈到了软件架构和函数式编程。
Sperber 给出了一个将系统代码划分为不同构建块的例子。这是一种特别重要的架构决策，可以单独处理不同的构建块，也可以与不同团队一起协作。实现这一点的一种方法是对粗粒度的构建块（有界上下文）使用领域驱动设计（DDD）：
DDD 是指，我们应该在开始时就通过上下文映射来识别有界上下文。但是，如果上下文之间的界限设置错了，我们就会丧失很多优势。我们会把它们搞错，至少会有一点点错误，然后之后就很难更改了。
根据 Sperber 的说法，与面向对象编程（OOP）相比，函数式编程能够支持后期架构并减少耦合。Sperber 认为，为了推迟宏观架构决策，我们必须始终保持解耦。他说，函数式编程中的组件本质上仅是数据类型和函数，这些函数在没有可变状态的情况下工作。与典型的 OO（面向对象）组件相比，这使得依赖关系更显式化，并且耦合更松散。这反过来又使我们能够构建独立于宏体架构的函数，Sperber 说到。
Sperber 明确表示，函数式编程并不“仅仅是没有可变状态的 OOP”。它有自己的领域建模、抽象和软件构建方法和文化。我们在 OO（面向对象）项目中可以通过采用不变性来获得一些好处。正如 Sperber 所解释的那样，要获得所有这些，我们需要更深入地研究，并使用适当的函数式语言：
函数式架构广泛使用高级抽象来实现可重用的组件，更重要的是，提供可预测未来的灵活领域模型。在探索和开发这些领域模型时，函数式程序员经常利用数学提供的丰富词汇表。由此产生的抽象从根本上说是由函数语言所提供的高级抽象设施实现的。
InfoQ 采访了 Michael Sperber，探讨了当前的架构技术工具箱是如何使我们更倾向于做出糟糕的决策，而这些决策在以后很难更改，以及如何解决这个问题。
InfoQ：在项目开始时，定义宏观架构的挑战有哪些？
MichaelSperber：软件架构的一个流行定义是，它是以后很难更改的决策。在开始时就这样做意味着是在你掌握的信息最少时做决策。因此，这些决策很有可能是错误的。
InfoQ：在上下文之间移动边界变得如此困难的原因是什么？
Sperber：在架构界，我们似乎忘了如何在有界上下文或单体中实现模块化，这就是为什么会有“模块化”这个新术语的原因，这意味着常规单体在默认情况下是非模块化的，其内部是紧密耦合的。
InfoQ：所以你的意思是说我们不知道如何在单体中实现松耦合？
Sperber：是的。这是因为 OO（面向对象）架构的基础是使用可变状态进行编程，即在适当的位置更改对象。这些状态变化导致了不可见的依赖关系，这些依赖关系很难被看见，并且会使构建块纠缠在一起。这不仅会影响项目的功能，还会影响其他质量目标。
InfoQ：你能举个例子吗？
Sperber：假设我们选择并行来作为实现高性能的策略：我们需要选择聚合根，并通过互斥来保护对这些根的访问。这是一项乏味的工作，容易出错，也难以快速完成，并且会极大地增加耦合。
InfoQ：如果架构师和开发人员想改进他们做出架构决策的方式，你有什么建议能给到他们？
Sperber：即使我们不能在项目中使用函数式语言，也可以尝试一下函数式编程的基础知识，感受一下其中的差异和机会。如果你是 FP（函数式编程）的新手，推荐你采用“如何设计程序”作为入门指南，如何你是德语使用者，则推荐 DeinProgramm。
另外推荐两本关于函数编程软件构建的书：
Scott Wlaschin：领域建模函数化
Sandy Maguire：代数驱动设计
原文链接：
https://www.infoq.com/news/2023/04/late-arch-functional-programming/
声明：本文为 InfoQ 翻译，未经许可禁止转载。