整洁架构
整洁架构，也被叫做“洋葱架构”，这个名字源于它极具特色的分层设计。观察相关示意图，能清晰发现整洁架构的各层次恰似一片片洋葱鳞片，层层相裹，生动形象地呈现出分层设计理念。
在整洁架构体系里，以同心圆来表示应用软件的不同构成部分。从最核心的内层起，由内至外依次为领域模型、领域服务、应用服务，而最外层是容易产生变化的内容，像用户界面与基础设施。领域模型处于核心关键位置，承载着业务的核心概念与规则；领域服务基于领域模型，提供相关业务逻辑服务；应用服务负责协调不同的领域服务，以契合具体应用场景的需求；最外层的用户界面和基础设施即便容易变动，但借助这种分层架构，它们的改变难以对核心业务逻辑造成影响。
整洁架构最为重要的原则当属依赖原则。此原则明确了各层之间的依赖关系：越靠近内层，依赖程度越低，代码的级别越高，代表着系统的核心能力。并且，外层代码的依赖方向只能指向内层，内层代码无需了解外层的任何状况。这种依赖规则确保了核心业务逻辑的稳定性与独立性，让系统在面对外部变化时，依旧能够维持核心功能正常运行，极大程度地增强了软件系统的可维护性和可扩展性。
洋葱架构，也就是整洁架构，以独特的分层设计为核心要点。从架构图中能够看出，其各层如同洋葱那样层层嵌套，这种设计理念直观且层次感分明。
在洋葱架构中，各层职能划分得十分清晰。最核心的领域模型，承载着领域内的核心业务逻辑，封装着企业级业务规则。领域模型的主体是实体，实体既可以是带有方法的对象，也可以是数据结构与方法的集合体，它是业务规则的具体承载者。
领域服务主要负责处理涉及多个实体的复杂业务逻辑。当业务逻辑涉及多个实体的交互与协作时，领域服务便开始发挥作用，对这些复杂逻辑进行整合与实现。
应用服务主要围绕用户操作展开，进行服务的组合与编排工作。它涵盖了应用特有的业务流程规则，将系统所有用例进行封装与实现，是连接用户操作与底层业务逻辑的关键纽带。
最外层的主要职能是提供适配能力，具体可分为主动适配和被动适配。主动适配面向外部用户、网页、批处理以及自动化测试等，实现它们对内层业务逻辑的访问适配；被动适配则是为核心业务逻辑访问基础资源，例如数据库、缓存、文件系统和消息中间件等提供适配。
特别值得一提的是，红圈内的领域模型、领域服务和应用服务共同构成了软件的核心业务能力。这三部分紧密协同合作，领域模型提供基础规则，领域服务处理复杂逻辑，应用服务负责面向用户的业务流程编排，它们是软件能够正常运转、发挥核心价值的关键所在。
DDD 分层架构
DDD 分层架构，也就是领域驱动设计分层架构，是一种构建软件系统的有效架构模式。它一般把系统划分成用户接口层、应用层、领域层和基础层这几个层次。
其中，用户接口层承担着与用户交互的任务，负责接收用户请求，并将响应结果清晰展示给用户；应用层就像一个协调者，主要处理用户请求，通过协调领域层的服务来完成各项业务操作，再把处理结果反馈给用户接口层；领域层作为核心层，囊括了业务领域的核心概念、规则和逻辑，是实现业务核心功能的关键所在；基础层则为其他层提供诸如数据访问、消息队列、缓存等通用的基础设施服务。这种架构凭借清晰的层次划分，有助于提升软件的可维护性、可扩展性和可测试性，让开发人员能够更加专注于业务逻辑的实现，从而更好地应对复杂业务场景的变化。
接下来，让我们看一下这张图。在早期的传统四层架构里，基础层（Infrastructure Layer）处于架构核心位置，被其他层所依赖。但依据分层架构的设计理念，领域层（Domain Layer）才是软件的核心，所以这种依赖关系存在明显问题。为解决该问题，我们引入了依赖倒置原则（Dependency Inversion Principle, DIP），对传统的四层架构进行优化，成功实现了各层与基础层的解耦。
六边形架构
六边形架构，也叫 “端口适配器架构”。在探寻微服务架构发展脉络时，它是不可忽视的重要概念。其核心理念着重于应用与外部的交互方式，即应用借助端口与外部进行交互，这也是微服务架构中 API 网关广泛应用的关键因素。
从架构图可知，在六边形架构里，红圈内的核心业务逻辑（涵盖应用程序和领域模型）与外部资源（如 APP、Web 应用及数据库资源等）完全隔离，二者仅通过适配器交互。这种设计巧妙解决了业务逻辑与用户界面代码相互交织的问题，出色地实现了前后端分离，让前端专注于用户交互展示，后端聚焦于业务逻辑处理，提高了系统的可维护性和可扩展性。
值得一提的是，六边形架构各层的依赖关系和整洁架构相同，都是由外向内依赖。外层的各类资源依赖内层的核心业务逻辑，而内层核心业务逻辑无需知晓外层资源的具体情况，保障了核心业务的稳定与独立，使系统面对外部变化时仍能稳定运行。
六边形架构将系统分为内六边形和外六边形两层，职能划分如下：红圈内的六边形实现应用的核心业务逻辑；外六边形负责完成与外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。六边形架构的一个端口可能对应多个外部系统，不同外部系统也可能使用不同适配器，由适配器负责协议转换，这让应用程序能以统一方式供用户、程序、自动化测试和批处理脚本使用。
三种微服务架构模型的对比和分析
DDD 分层架构、整洁架构、六边形架构虽表现形式有别，但设计思想一致，都体现了微服务架构高内聚低耦合的原则。
高内聚是把相关功能和数据整合为独立模块，专注特定任务；低耦合则是降低模块间的依赖，增强系统灵活性和可维护性。这三种架构通过不同方式，实现模块独立和依赖弱化，让各部分协同工作。
它们都以领域模型为核心。领域模型是业务核心知识的抽象，是架构的基石。围绕它，不同架构构建起交互和业务逻辑处理体系，保障核心业务稳定运行，为微服务架构搭建提供支撑。
观察图示能发现，DDD 分层架构、整洁架构和六边形架构虽呈现形式不同，但共性显著。三种架构中都有红色线框作为重要分界线，其关键作用是将核心业务逻辑与外部应用、基础资源隔离开来。
在红色框内部，虽都实现核心业务逻辑，但业务逻辑存在功能差异。基于此差异，三种架构划分出应用层和领域层，分别承担不同类型的业务逻辑。
- 领域层：作为原子模型，面向领域模型，实现领域模型的核心业务逻辑。它处于架构核心位置，需保持领域模型和业务逻辑稳定，对外提供稳定的细粒度领域服务。因为在企业运营中，只要没有重大变革，核心领域逻辑基本不变。
- 应用层：面向用户操作相关的用例和流程，如同配速齿轮，处于前台应用和领域层之间。它对外提供粗粒度的 API 服务，负责接收前台需求，及时响应调整，尽量避免将前台需求直接传导至领域层。通过服务组合和编排，应用层能快速适配业务流程并上线，以应对因用户体验、操作习惯、市场环境和管理流程等变化导致的界面逻辑和流程多变。
总体而言，这三种架构充分考虑了前端需求的多变性和领域模型的相对稳定性。通过分层设计，有效控制需求变化从外到内对系统的影响，让面向用户的前端能灵活快速响应外部需求进行调整和发布，同时使领域层长期保持稳定。这种设计对构建前台灵活、中台稳固的架构很有帮助。
看到这里，相信大家对中台和微服务设计的关键已有思考。在我看来，答案是领域模型和微服务的合理分层设计，那你心中的答案是什么呢？
从三种架构模型看中台和微服务设计
前文所述的DDD分层架构、整洁架构以及六边形架构，尽管外在呈现形式各有差异，却有着极为显著的共性。这三种架构都借助类似红色线框这样关键的分界线，把核心业务逻辑与外部应用、基础资源分隔开来，同时都划分出应用层和领域层，凭借不同的功能定位，来应对前端需求的多变以及领域模型的相对稳定。
基于这些架构模型的共性，我想谈谈对于中台和微服务设计的一些感悟。中台，从本质来讲，是领域的子域，它既可能是关乎业务核心的核心域，也可能是提供通用能力的通用域，或者是起到支撑作用的支撑域。就拿阿里中台来说，许多人认为它对应DDD中的通用域，其作用在于沉淀通用的公共能力，进而对外提供通用共享服务。
中台作为子域，还有进一步细化的空间，能够继续拆解为子子域。当子域被分解到合适规模后，通过事件风暴划分限界上下文，就可以着手定义微服务了。微服务的作用在于实现中台的能力，它将中台的复杂功能拆解成一个个小型、独立的服务，从而实现更灵活高效的运行。
乍看之下，DDD、中台和微服务这三者之间似乎关联并不明显，但实际上，它们的关系紧密相连。DDD提供了领域驱动的设计理念，助力我们更透彻地理解业务领域；中台作为业务能力的沉淀和共享平台，是实现业务复用和快速响应变化的关键；微服务则凭借其独立部署、灵活扩展的特性，支撑着中台能力的具体实现。这三者相互配合，共同构成了一个完整的理论体系，为中台和微服务设计提供了强有力的指导。
1. 中台建设要聚焦领域模型
中台在企业架构里占据着举足轻重的地位，它需要从全企业的宏观视角出发，充分考虑能力的共享与复用。中台设计并非易事，它要求我们构建中台内所有限界上下文的领域模型。
在运用DDD进行建模的过程中，我们不仅要深入剖析业务逻辑，还需前瞻性地思考架构未来的演进方向，以及功能在不同场景下的重新组合。这一领域模型的构建过程，如同一场精细的手术，会对业务与应用进行清晰的逻辑和物理边界划分，而这些边界往往与微服务的架构紧密相关。
领域模型一旦确定，其影响力将贯穿整个系统开发流程。它就像基石一样，直接作用于后续系统模型、架构模型以及代码模型的构建。从更实际的角度来看，领域模型的质量和合理性，最终会深刻影响微服务的拆分策略和项目的落地实施。
倘若领域模型构建不完善，微服务拆分可能缺乏合理性，导致服务之间协作出现问题，影响系统的整体性能和稳定性。而一个优质的领域模型，能为微服务拆分提供科学依据，确保各个微服务既具备独立性，又能高效协同工作，推动项目顺利落地。
由此可见，在中台设计的复杂体系中，领域模型应被摆在核心位置。我们务必聚焦领域模型的构建，投入充足的时间和精力，为中台乃至整个企业的数字化架构筑牢根基。
2. 微服务要有合理的架构分层
微服务设计需秉持分层思想，让各层明确分工，构建松耦合的层间关系。领域层应专注于实现领域逻辑，杜绝无关逻辑混入，以此维护其纯洁性与稳定性，防止领域模型被污染。同时，也不能将领域模型的业务逻辑置于应用层，否则会使应用层变得臃肿，导致领域模型失去焦点。若难以避免逻辑交叉，可引入防腐层，用于新老系统的适配与转换，待过渡期结束后便可舍弃其代码。
了解微服务内部的分层方式后，再来看看微服务之间的关系。微服务之间存在层次依赖关系，并且在服务集成上也有不同方式。比如，项目级微服务可与前端应用集成，共同完成特定业务；而企业级中台微服务职责单一，需要多个此类微服务组合，才能完成企业级业务流程。由于复杂度不同，这两类微服务的集成方式也有所区别。
项目级微服务
项目级微服务的内部遵循分层架构模型就可以了。领域模型的核心逻辑在领域层实现，服务的组合和编排在应用层实现，通过 API 网关为前台应用提供服务，实现前后端分离。但项目级的微服务可能会调用其它微服务，你看在下面这张图中，比如某个项目级微服务 B 调用认证微服务 A，完成登录和权限认证。
通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在 API 网关上的应用服务。你看下图中微服务 B 中红色框内的应用服务 B，它除了可以组合和编排自己的领域服务外，还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到 API 网关供前端调用，这样前端就可以直接访问自己的微服务了。
企业级中台微服务
在企业级业务流程中，往往需要多个中台微服务协同工作，那么跨中台的微服务该如何实现集成呢？要知道，企业级中台微服务的集成与项目级微服务不同，无法在单个微服务内完成跨微服务的服务组合与编排。
为了解决这个问题，我们可以在中台微服务之上新增一层。从下方图示中可以看到，新增的这一层位于红色框内，它承担着关键职能。一方面，负责处理跨中台微服务的服务组合和编排，以及协调各微服务之间的工作；另一方面，还能够完成前端不同渠道应用的适配。
如果进一步拓展其业务范围，我们完全可以将它打造成一个面向不同行业和渠道的服务平台。这里，我们借用 “BFF（服务于前端的后端，Backend for Frontends）” 一词，暂且称它为 BFF 微服务。BFF 微服务与其他普通微服务有着显著差异，它没有领域模型，相应地，这个微服务内也就不存在领域层。
BFF 微服务主要承担应用层和用户接口层的职能，能够高效地完成各个中台微服务的服务组合和编排，并且可以灵活适配不同前端和渠道的多样化要求，为企业级业务流程的顺利开展提供有力支持
3. 应用和资源的解耦与适配
在传统以数据为中心的设计模式下，应用与数据库、缓存、文件系统等基础资源之间存在着紧密的依赖关系。这种强依赖意味着，一旦基础资源发生变动，例如更换数据库，应用就会受到极大的冲击，可能导致功能异常、运行效率降低甚至系统崩溃。
为了改变这一现状，实现应用与资源的解耦显得尤为重要。在微服务架构中，应用层、领域层和基础层通过仓储模式，运用依赖倒置的设计方法达成解耦。仓储模式就像是在应用与基础资源之间搭建了一座桥梁，它抽象出对基础资源的访问操作，使得应用层和领域层无需直接与具体的基础资源交互。依赖倒置则让高层次的模块不依赖于低层次模块的具体实现细节，而是依赖于抽象接口。
在应用设计阶段，同步考虑与基础资源的代码适配工作，能够有效屏蔽资源变更对业务代码的影响。当基础设施资源发生变更时，只需在仓储层对相关接口实现进行调整，业务逻辑代码无需改动，从而成功切断业务逻辑对基础资源的依赖，将资源变更给应用带来的影响降至最低。这种设计不仅提升了应用的稳定性和可维护性，还为系统的持续发展和升级提供了有力保障 。
总结
今天我们详细讲解了整洁架构和六边形架构，并对包括 DDD 分层架构在内的三种微服务架构模进行对比分析，总结出了它们的共同特征，并从共性出发，梳理出了中台建模和微服务架构设计的几个要点，我们后面还会有更加详细的有关设计落地的讲述。
那从今天的内容中我们不难看出： DDD 分层架构、整洁架构、六边形架构都是以领域模型为核心，实行分层架构，内部核心业务逻辑与外部应用、资源隔离并解耦。请务必记好这个设计思想，今后会有大用处。
文章来源： https://study.disign.me/article/202509/9.microservice-models.md
发布时间: 2025-02-25
作者： 技术书栈编辑