汕头做网站多少钱,下载百度网盘,php建网站教程,手机自适应网站在完成领域模型设计后#xff0c;接下来我们就可以开始微服务的设计和 落地了。在微服务落地前#xff0c;⾸先要确定微服务的代码结构#xff0c;也就是我 下⾯要讲的微服务代码模型。 只有建⽴了标准的微服务代码模型和代码规范后#xff0c;我们才可以将 领域对象映射到… 在完成领域模型设计后接下来我们就可以开始微服务的设计和 落地了。在微服务落地前⾸先要确定微服务的代码结构也就是我 下⾯要讲的微服务代码模型。 只有建⽴了标准的微服务代码模型和代码规范后我们才可以将 领域对象映射到代码对象并将它们放⼊合适的代码⽬录结构中。标 准的代码模型可以让项⽬团队成员更好地理解代码根据统⼀的代码 规范实现团队协作也可以让微服务各层的业务逻辑互不⼲扰、分⼯ 协作、各据其位、各司其职避免不必要的代码混淆还可以让你在 微服务架构演进时轻松完成代码重构。
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分层架构模型的微服务可能会慢 慢变回原来紧耦合的传统三层架构这样是不利于未来微服务架构的 演进的。
