是否有任何关于企业架构模式（a la Fowler's）的（集中）信息的良好来源，可能包含示例和用例以及大量实用信息？例如，我在一些 SO 帖子和其他站点中看到了许多 GoF 的设计模式，以及与它们相关的实用信息。我正在从面向企业应用程序的功能性更强的范例中寻求类似的资源。
谢谢。
【问题讨论】：
标签： design-patterns functional-programming enterprise
我从面向企业应用程序的功能性更强的范例中寻求类似的资源。
没有我知道的资源。大型企业使用现代 FP 的时间通常小于 10 年，因此资源往往以互联网形式存在。此外，很多人避免使用 GoF，因为它与 FP 在很大程度上无关。
SO 仍然是您的最佳选择（这里有一个示例：https://*.com/a/3077912/83805）。不过，FP 架构书是有市场的，这是肯定的。
社论
根据我的经验，几乎所有设计都属于“编译器”或“解释器”模式，使用数据模型和基于该数据的函数。也就是说，问题域被表示为代数结构（对象作为 ADT，其上有函数），软件架构是关于从一个代数到另一个代数的映射。这就是“范畴论”设计模式（！）
我们的代数数据类型是捕获结构的最佳方式。函数是转换这些结构或将它们映射到新类型结构的最佳方式。并且有很多关于编写编译器和解释器的研究使这些事情变得容易。您可以通过编写编译器（或解释器）来实现大多数系统。所以学习编写编译器。
当您开始寻找这些“分类”软件问题时，会出现很多解释器或编译器的问题，这真是令人惊讶。像 MVC 这样的东西会作为解释器出现。许多商业软件（数据处理）变成了解析器+分析+漂亮的打印机——即编译器。也许很明显，架构（即如何粘合组件）实际上是关于代数和类别的。
显然，这是关于高级架构的。较低级别的事情，例如如何最好地实现日志系统，或者如何最好地连接昂贵的组件，如何传递环境，重放/回滚确实有特定的抽象，你可以重用是一个不同的问题。通常是 monoids/monads/applicatives 或其他作为库捕获的计算概念。
不过，我们再次进入代数视图，以找到最能捕捉问题域的结构。
【讨论】：