微服务架构：从事务脚本到领域模型
图1 Order Service具有六边形架构。它由业务逻辑和一个或多个与其他服务和外部应用程序连接的适配器组成
REST API adapter：入站适配器，实现REST API，这些API会调用业务逻辑。 OrderCommandHandlers：入站适配器，它接收来自消息通道的命令式消息，并调用业务逻辑。 Database Adapter：由业务逻辑调用以访问数据库的出站适配器。 Domain Event Publishing Adapter：将事件发布到消息代理的出站适配器。
1 使用事务脚本模式设计业务逻辑
图2 将业务逻辑组织为事务脚本。在典型的基于事务脚本的设计中，一组类实现行为，另一组类负责存储状态。事务脚本通常被写成没有状态的类。脚本访问没有行为的数据类以完成持久化的任务
2 使用领域模型模式设计业务逻辑
在面向对象的设计中，业务逻辑由对象模型和相对较小的一些类的网络组成。这些类通常直接对应于问题域中的概念。在这样的设计中，有些类只有状态或行为，但很多类同时包含状态和行为，这样的类都是精心设计的。图3显示了领域模型模式的示例。
图3 将业务逻辑组织为领域模型。大多数业务逻辑由具有状态和行为的类组成
与事务脚本模式一样，OrderService类具有针对每个请求或系统操作的方法。但是在使用领域模型模式时，服务方法通常很简单。因为服务方法几乎总是调用持久化领域对象，这些对象中包含大量的业务逻辑。例如，服务方法可以从数据库加载领域对象并调用其中一个方法。在这个例子中，Order类具有状态和行为。此外，它的状态是私有的，只能通过它的方法间接访问。
使用面向对象设计有许多好处。首先，这样的设计易于理解和维护。它不是由一个完成所有事情的大类组成，而是由许多小类组成，每个小类都有少量职责。此外，诸如Account、BankingTransaction和OverdraftPolicy这些类都密切地反映了现实世界，这使得它们在设计中的角色更容易理解。其次，我们的面向对象设计更容易测试：每个类都可以并且应该能够被独立测试。最后，面向对象的设计更容易扩展，因为它可以使用众所周知的设计模式，例如策略模式（Strategy pattern）和模板方法模式（Template methodpattern），这些设计模式定义了在不修改代码的情况下扩展组件的方法。
领域建模模式看似完美，但这种方法同样也存在许多问题，尤其是在微服务架构中。要解决这些问题，你需要使用称为领域驱动设计的思路来优化面向对象设计。
3 关于领域驱动设计
实体（entity）：具有持久化ID的对象。具有相同属性值的两个实体仍然是不同的对象。在Java EE应用程序中，使用JPA @Entity进行持久化的类通常是DDD实体。 值对象（value object）：作为值集合的对象。具有相同属性值的两个值对象可以互换使用。值对象的一个例子是Money类，它由币种和金额组成。 工厂（factory）：负责实现对象创建逻辑的对象或方法，该逻辑过于复杂，无法由类的构造函数直接完成。它还可以隐藏被实例化的具体类。工厂方法一般可实现为类的静态方法。 存储库（repository）：用来访问持久化实体的对象，存储库也封装了访问数据库的底层机制。 服务（service）：实现不属于实体或值对象的业务逻辑的对象。
本文摘自《微服务架构设计模式》，经出版方授权发布。
点击上图了解及购买
《微服务架构设计模式》
作者：：[美] 克里斯·理查森（Chris Richardson） 著
译者：喻勇 译
推荐语：
微服务架构的先驱、Java 开发者社区的意见领袖 Chris Richardson亲笔撰写，微服务实用落地指南 。
涵盖44个架构设计模式，系统解决服务拆分、事务管理、查询和跨服务通信等难题
易宝支付CTO陈斌、PolarisTech 联合创始人蔡书、才云科技CEO张鑫等多位专家鼎力推荐。
点击“阅读原文”挑选更多微服务好书！
往期推荐：
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。