《微服务架构设计模式》阅读笔记（三）

第5章 微服务架构中的业务逻辑设计

图5-1显示了一个典型的服务架构。业务逻辑是六边形架构的核心。业务逻辑的周围是入站和出站适配器。入站适配器处理来自客户端的请求并调用业务逻辑。出站适配器被业务逻辑调用，然后在调用其他服务和外部应用程序。

业务逻辑通常是服务中最复杂的部分。在开发业务逻辑时必须做出的关键决策是选用面向对象的方式，还是面向过程的方式。组织业务逻辑主要有两种模式：面向过程的事务脚本模式和面向对象的领域建模模式。

5.1.1 使用事务脚本设计业务逻辑

事务脚本的一个重要特征是实现行为的类与存储状态的类是分开的。

使用事务脚本模式时，脚本通常位于服务类中，在此实例中是OrderService类。每个服务类都有一个用于请求或系统操作的方法。这个方法实现该请求的业务逻辑。它使用数据访问对象（DAO）访问数据库。数据对象（Order）是纯数据，几乎没有行为。

5.1.2 使用领域模型模式设计业务逻辑

实际上，就像单体应用程序不断增长的趋势一样，事务脚本也存在同样的问题。因此，除非是编写一个非常简单的应用程序，否则你应该抵制编写面向过程的代码的诱惑，使用领域模型模式，并进行面向对象的设计。
在面向对象的设计中，业务逻辑由对象模型和相对较小的一些类的网络组成。这些类通常知己诶对应于问题域中的概念。在这样的设计中，有些类只有状态和行为，但很多类同时包含了状态和行为，这样的类都是精心设计的。图5-3展示了领域模型模式的示例。

使用面向对象设计有许多好处。首先，这样的设计易于理解和维护。它不是由一个完成所有事情的大类组成，而是由许多小类组成，每个小类都有少量的职责。其次，我们的面向对象设计更容易测试：每个类都可以并且应该能够被独立测试。最后，面向对象的设计更容易扩展，因为它可以使用众所周知的设计模式。

5.1.3 关于领域驱动设计

详见《领域驱动设计-软件核心复杂性应对之道》阅读笔记

5.2 使用聚合模式设计领域模型

5.2.