原副标题：【构架与结构设计】常用微服务项目多层构架的差别和破冰课堂教学
译者：天猫信息技术 康志兴
序言
从特别强调与外隔绝的八边形构架，逐渐发展派生出的一层层环环相扣、著重应用领域数学模型的卷心菜构架，再到和DDD轻松切合的干净构架。构架艺术风格的不断重构，其实是为了适应环境应用软件需求越来越繁杂的特征。
能看到，越现代的构架艺术风格越偏激于明晰的职能功能定位，且让应用领域数学模型成为构架的核心理念。
如前所述这些构架艺术风格，在应用软件构架结构设计过程中又有十分多的构架多层数学模型。
现代四层构架
现代服务项目一般来说采用四层构架：
• 门铆接：做为服务项目曝露的出口处，处理大部份的内部允诺。部分情况下，门铆接甚至不需要准则上表述第一类而是间接采用服务项目层的虚拟表述。
• 服务项目层：做为核心理念销售业务层，包涵大部份销售业务方法论。并对此基础层潜能展开单纯女团提供一定的潜能F83E43Se。一般来说服务项目Eurotium展开虚拟表述来避免上层第一类体间接曝露给内部服务项目，导致上层任何变化都有可能间接传达到内部，十分不稳定。
• 此基础层：用以放置dao和内部rpc服务的PCB，两者能拆分为相同的module，也可合而为一，以相同package展开隔绝。
四层构架特征是单纯，适用于于许多无繁杂销售业务情景的较大型应用，或者“统计数据不可变”做为此基础准则的DOP（面向全国统计数据程式设计）服务项目。
但是当销售业务情景稍稍繁杂许多、初始化层次非常多时，可F83E43Se性、可移植性就都十分差了，很多标识符都谐振在一起，牵一策动浑身。
DDD构架
DDD构架能看做是干净构架的一种实现，多层职能如下：
• 适配层：用以做内部相同端允诺的适配器，隔绝相同端的协议差异，包装相同端相同样式的响应体。
• 应用层：用例、任务出口处、消息队列监听均在这一层，能理解为销售业务流程的出口处，通过聚合根的构造执行相应的命令操作。
• 应用领域服务项目层：包涵核心理念的应用领域服务项目表述，并表述了gateway来做一层依赖倒置，使此基础设施层仅做实现。
• 此基础设施层包涵一切此基础潜能：统计数据库、ES、远程初始化PCB等等。
优点
• 核心理念稳定：应用领域数学模型在依赖链上是顶层角色，不依赖任何其他模块，所以极其稳定。其他任何销售业务域、存储、边缘潜能的变化都不会对应用领域数学模型造成影响。
• 敏捷：适合相同团队一起开发和维护而不会产生冲突。
• 可拆分：当有届上下文随着重构逐渐膨胀时，很容易拆分成微服务项目。
• 可扩展：添加新的功能十分单纯，从而使得开发人员能够更快的部署和调整。
• 可重构：良好的可测试性带来十分低的重构成本，不会随着不断迭代导致项目成为难以修改的“大泥球”。
如此多的优点自然带来明确的缺点
• 专业性要求较高：需要对销售业务、构架准则理解深刻的人员展开结构设计和维护，不恰当的应用领域数学模型将使后续迭代极为痛苦。
• 开发成本高：繁杂的构架结构设计，更多的构架多层，自然带来标识符行数的指数级增长。尤其是项目前期的开发任务变得异常繁重。
• 不再适合单纯的销售业务情景：实现一个单纯的CRUD显得过于繁杂。
• 改变决策困难：尝试采用干净构架需要和团队的管理层和其他成员达成一致，这往往需要十分强大的说服力。如果在构架重构过程中想切换回其他构架模式也十分困难，几乎是整个项目级别的重构工作。
单纯的微服务项目多层构架
如前所述八边形构架规范的接口适配准则和防腐理念，同时借鉴了CQRS模式的优点，我们表述了一个单纯的微服务项目多层构架。
多层表述如下：
• 门铆接：做为程序的出口处，通过包隔绝来放置JSF服务项目、Rest服务项目、定时任务和MQ消费，其中对外提供服务项目的接口表述放置在准则上的api包中。该层的允诺表述命名以Request结尾，响应体命名以Response结尾。
• 应用领域服务项目层：每一个应用领域服务项目放置在准则上的module中，并通过准则上的api包对外曝露潜能。该层的命令允诺表述命名以Command结尾，查询允诺表述命名以Query结尾，响应体命名以Dto结尾。
• 此基础设施层：放置统计数据库、ES、远程初始化服务项目的PCB。该层的持久化统计数据表述命名以Po结尾。远程命令服务项目入参命名以RpcCommand结尾，远程查询服务项目入参命名以RpcQuery结尾，响应体命名以RpcDto结尾。
最佳课堂教学
命令服务项目必须访问应用领域服务项目层，允许单纯查询间接初始化此基础设施层。 参数校验、允诺出入参日志、审计日志记录、TraceID预埋、异常处理等非核心销售业务潜能均由公共组件完成，减少项目内部的边缘潜能标识符。 由于在门铆接展开统一的异常处理，非必要时无需在项目中展开大面积的try-catch，让标识符更清爽。 实际开发过程中，门铆接、领域服务项目层和此基础设施层均有各自的虚拟表述，跨层初始化的第一类体转换采用MapStruct组件来减少手写映射标识符的工作量。 统计数据层采用Fluent-Mybatis，最大好处是减少后期迭代中，统计数据第一类增减字段时修改Mapper的成本。优点
1. 开发效率
单纯的销售业务开发过程中，相比较书写核心理念销售业务方法论，更多的工作量几乎都是来自处理跨层初始化时第一类转换和Mapper表述，通过MapStruct和Fluent-Mybatis等组件的采用（也许再加上GitHub Copilot😁），编写一个虚拟的增删改查接口基本在5分钟内搞定，省下来的时间能多走读两遍标识符或者多写几个分支的测试用例，也算是降本增效了。
2. 服务项目隔绝
通过module隔绝相同的应用领域服务项目，降低相同应用领域服务项目之间的谐振程度。
3. 内部服务项目防腐
远程初始化统一PCB在此基础设施层中，降低内部变化对系统内部的影响。
缺点
此基础设施层的虚拟做为顶层依赖由于对此基础设施层的依赖没有通过api包展开隔绝，所以此基础设施层的第一类会间接曝露在应用领域服务项目层和门铆接。对此能通过采用ArchUnit组件展开构架防腐。
如果需要表述完善的应用领域虚拟充血数学模型，建议参考DDD构架表述gateway层来展开此基础设施层的依赖倒置。
最后
应用软件工程的方方面面都遵循一个最基本的道理：没有银弹，构架多层数学模型更是如此，每一种都有各自优缺点，所以请根据相同的销售业务情景，并遵循单纯、可重构这两个重要的架构准则选择合适的构架多层数学模型即可。
构架不只是工作，更是一门艺术。
