在完成领域模型设计后，接下来我们就可以开始微服务的设计和 落地了。在微服务落地前，⾸先要确定微服务的代码结构，也就是我 下⾯要讲的微服务代码模型。

        只有建⽴了标准的微服务代码模型和代码规范后，我们才可以将 领域对象映射到代码对象，并将它们放⼊合适的代码⽬录结构中。标 准的代码模型可以让项⽬团队成员更好地理解代码，根据统⼀的代码 规范实现团队协作，也可以让微服务各层的业务逻辑互不⼲扰、分⼯ 协作、各据其位、各司其职，避免不必要的代码混淆，还可以让你在 微服务架构演进时，轻松完成代码重构。

DDD分层架构与微服务代码模型

        我们参考DDD分层架构模型来设计微服务代码模型。没错！微服 务代码模型就是依据DDD分层架构模型设计出来的。

        我们先简单回顾⼀下DDD分层架构模型，如图14-1所⽰。它包括 ⽤户接⼝层、应⽤层、领域层和基础层，分层架构各层的职责边界⾮ 常清晰，能有条不紊地分层协作。

• ⽤户接⼝层：⾯向前端⽤户提供服务和数据适配。这⼀层聚集了 接⼝和数据适配相关的功能。
• 应⽤层：实现服务组合和编排，主要适应业务流程快速变化的需 求。这⼀层聚集了应⽤服务和事件订阅相关的功能。
• 领域层：实现领域模型的核⼼业务逻辑。这⼀层聚集了领域模型 的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，通过 各领域对象的协同和组合形成领域模型的核⼼业务能⼒。
• 基础层：它贯穿所有层，为各层提供基础资源服务。这⼀层聚集 了各种底层资源相关的服务和能⼒。

        领域模型的业务逻辑从领域层、应⽤层到⽤户接⼝层逐层组合和 封装，对外提供灵活的服务。既实现了各层的分⼯和解耦，⼜实现了 各层的协作。因此，⽏庸置疑，DDD分层架构模型是微服务代码模型 最合适的选择。

微服务代码模型

        其实，DDD并没有给出标准的代码模型，不同的⼈可能会有不同 理解，也会结合⾃⼰项⽬的情况进⾏个性化设计。下⾯要说的这个微 服务代码模型是我经过思考和实践后建⽴起来的，主要考虑了微服务 边界、聚合边界、分层、解耦和微服务的架构演进等因素.

⼀级代码⽬录

        微服务⼀级⽬录是按照DDD分层架构的分层职责来定义的。 在微服务代码模型⾥，我们分别定义了⽤户接⼝层、应⽤层、领 域层和基础层四层，并分别为它们建⽴了interfaces、application、 domain和infrastructure四个⼀级代码⽬录。

这些代码⽬录的职能和代码形态如下。

• interfaces（⽤户接⼝层）：它主要存放⽤户接⼝层与前端应⽤交 互、数据转换和交互相关的代码。前端应⽤通过这⼀层的接⼝，从应 ⽤服务获取前端展现所需的数据。处理前端⽤户发送的REStful请求， 解析⽤户输⼊的配置⽂件，并将数据传递给application层。数据的组 装、数据传输格式转换以及facade接⼝封装等代码都会放在这⼀层⽬ 录⾥。
• application（应⽤层）：它主要存放与应⽤层服务组合和编排相 关的代码。应⽤服务向下基于微服务内的领域服务或外部微服务的应 ⽤服务，完成服务的组合和编排，向上为⽤户接⼝层提供各种应⽤数 据⽀持服务。应⽤服务和事件等代码会放在这⼀层⽬录⾥。
• domain（领域层）：它主要存放与领域层核⼼业务逻辑相关的代 码。领域层可以包含多个聚合代码包，它们共同实现领域模型的核⼼ 业务逻辑。聚合内的聚合根以及实体、⽅法、值对象、领域服务和事 件等相关代码会放在这⼀层⽬录⾥。
• infrastructure（基础层）：它主要存放与基础资源服务相关的代 码。为其他各层提供的通⽤技术能⼒、三⽅软件包、数据库服务、配 置和基础资源服务的代码都会放在这⼀层⽬录⾥。

各层代码⽬录

下⾯我们⼀起来看⼀下⽤户接⼝层、应⽤层、领域层以及基础层 各⾃的⼆级代码⽬录结构。

1. ⽤户接⼝层

interfaces⽬录下的代码⽬录结构有assembler、dto和facade三类。

•  assembler：实现DTO与DO领域对象之间的相互转换和数据交 换。⼀般来说，assembler与dto总是同时出现。
• dto：它是前端应⽤数据传输的载体，不实现任何业务逻辑。我 们可以⾯向前端应⽤将应⽤层或领域层的DO对象转换为前端需要的 DTO对象，从⽽隐藏领域模型内部领域对象DO；也可以将前端传⼊的 DTO对象转换为应⽤服务或领域服务所需要的DO对象。
• facade：封装应⽤服务，提供较粗粒度的调⽤接⼝，或者将⽤户 请求委派给⼀个或多个应⽤服务进⾏处理。

2.应⽤层

application的代码⽬录结构有event和service，如图

• event（事件）：这层⽬录主要存放事件相关的代码。它包括两个 ⼦⽬录：publish和subscribe。前者主要存放事件发布相关代码，后者 主要存放事件订阅相关代码。事件处理相关的核⼼业务逻辑在领域层 实现。
• 应⽤层和领域层都可以进⾏事件发布。为了实现事件订阅的统⼀ 管理，建议你将微服务内所有事件订阅的相关代码都统⼀放到应⽤ 层。事件处理相关的核⼼业务逻辑实现可以放在领域层。通过应⽤层 调⽤领域层服务，来实现完整的事件订阅处理流程。
• service（应⽤服务）：这层的服务是应⽤服务。应⽤服务会对多 个领域服务或其他微服务的应⽤服务进⾏封装、编排和组合，对外提 供粗粒度的服务。你可以为每个聚合的应⽤服务设计⼀个应⽤服务 类。
• 另外，在进⾏跨微服务调⽤时，部分DO对象需要转换成DTO，所 以应⽤层可能也会有⽤户接⼝层的assembler和dto对象。这时，你可以 根据需要增加assembler和dto代码⽬录结构。

注意: 对于多表关联的复杂查询，由于这种复杂查询不需要有领域逻辑和业 务规则约束，因此不建议将这类复杂查询放在领域层的领域模型中。 你可以通过应⽤层的应⽤服务采⽤传统多表关联的SQL查询⽅式，也 可以采⽤CQRS读写分离的⽅式完成数据查询操作。 

3. 领域层 

        domain下的⽬录结构是由⼀个或多个独⽴的聚合⽬录构成，每⼀ 个聚合是⼀个独⽴的业务功能单元，多个聚合共同实现领域模型的核 ⼼业务逻辑。

        聚合内的代码模型是标准且统⼀的，它⼀般包括entity、event、 repository和service四个⼦⽬录。

         aggregate（聚合）：它是聚合⽬录的根⽬录，你可以根据实际项 ⽬的聚合名称来命名，⽐如将聚合命名为“Person”。

        聚合内实现⾼内聚的核⼼领域逻辑，聚合可以独⽴拆分为微服 务，也可以根据领域模型的演变，在不同的微服务之间进⾏聚合代码 重组。 将聚合所有的代码放在⼀个⽬录⾥的主要⽬的，不仅是为了业务 的⾼内聚，也是为了未来微服务之间聚合代码重组的便利性。有了清 晰的聚合代码边界，你就可以轻松地实现以聚合为单位的微服务拆分 和重组。 聚合之间的松耦合设计和清晰的代码边界，在微服务架构演进中 具有⾮常重要的价值。 聚合内可以定义聚合根、实体和值对象以及领域服务等领域对 象，⼀般包括以下⽬录结构。

• entity（实体）：它存放聚合根、实体和值对象等相关代码。实 体类中除了业务属性，还有业务⾏为，也就是实体类中的⽅法。如果 聚合内部实体或值对象⽐较多，你还可以再增加⼀级⼦⽬录加以区 分。
• event（事件）：它存放事件实体以及与事件活动相关的业务逻辑 代码。
• service（领域服务）：它存放领域服务、⼯⼚服务等相关代码。 ⼀个领域服务是由多个实体组合出来的⼀段业务逻辑。你可以将聚合 内所有领域服务都放在⼀个领域服务类中。如果有些领域服务的业务 逻辑相对复杂，你也可以将⼀个领域服务设计为⼀个领域服务类，避 免将所有领域服务代码都放在⼀个领域服务类中⽽出现代码臃肿的问 题。领域服务可以封装多个实体或⽅法供上层应⽤服务调⽤。
• repository（仓储）：它存放仓储服务相关的代码。仓储模式通常 包括仓储接⼝和仓储实现服务。它们⼀起完成聚合内DO领域对象的持 久化，或基于聚合根ID查询，完成聚合内实体和值对象等DO领域对象 的数据初始化。另外，仓储⽬录还会有持久化对象PO，以及持久化实 现逻辑相关代码，如DAO等。在仓储设计时有⼀个重要原则，就是⼀ 个聚合只能有⼀个仓储。

注意 按照DDD分层架构，仓储本应该属于基础层。但为了在微服务架构 演进时保证聚合代码重组的便利，这⾥将仓储相关代码也放到了领域 层的聚合⽬录中。 这是因为聚合和仓储总是⼀对⼀的关系，将领域模型和仓储的代码组 合在⼀起后，就是⼀个包含了领域层领域逻辑和基础层数据处理逻辑 的聚合代码单元。⼀旦领域模型发⽣变化，当聚合需要在不同的限界 上下⽂或微服务之间进⾏代码重组时，我们就可以以聚合代码包为单 元，进⾏整体拆分或者迁移，轻松实现微服务架构演进。虽然领域相关的业务逻辑代码和基础资源处理相关的代码都在⼀个聚 合代码⽬录下，但是聚合的核⼼业务逻辑仍然是通过调⽤仓储接⼝来 访问基础资源的仓储实现处理逻辑，所以这样不会影响业务逻辑与基 础资源逻辑的依赖倒置设计。

 4. 基础层

infrastructure的代码⽬录结构有config和util两个⼦⽬录

• config：主要存放配置相关代码
• util：主要存放平台、开发框架、消息、数据库、缓存、⽂件、 总线、⽹关、第三⽅类库和通⽤算法等基础代码。你可以为不同的资源类别建⽴不同的⼦⽬录

本章⼩结

        我们根据DDD分层架构模型，建⽴了微服务的标准代码模型。在 代码模型⾥⾯，各层的代码对象各据其位、各司其职，共同协作完成 微服务的业务逻辑。 关于微服务代码模型我还需要强调两点内容。 第⼀点，聚合之间的代码边界⼀定要清晰。

        聚合之间的服务调⽤ 和数据关联应该尽可能松耦合和低关联，聚合之间的服务调⽤应该通 过上层的应⽤层组合实现调⽤，原则上不允许聚合之间直接调⽤领域 服务。这种松耦合的聚合代码关联，在以后业务发展和需求变更时， 可以很⽅便地实现业务功能和聚合代码的重组，在微服务架构演进中 将会起到⾮常重要的作⽤。

         第⼆点，⼀定要有代码分层的概念。有了分层的思想后，写代码 时⼀定要搞清楚代码的职责，将它放在职责对应的代码⽬录内。应⽤ 层代码主要完成服务组合和编排，以及聚合之间的协作，它是很薄的 ⼀层，不应该有核⼼领域逻辑代码。领域层是领域模型的业务的核 ⼼，领域模型的核⼼逻辑代码⼀定要在领域层实现。如果将核⼼领域 逻辑代码放到应⽤层，你的基于DDD分层架构模型的微服务可能会慢 慢变回原来紧耦合的传统三层架构，这样是不利于未来微服务架构的 演进的。