本文将对比分析DDD分层架构、整洁架构、六边形架构。
又名“洋葱架构”(看图就懂),体现了分层思想。
同心圆代表应用软件的不同部分,由内到外依次是
该架构最主要原则:依赖原则,它定义了各层依赖关系,越往内依赖越低,代码级别越高,能力越核心。外圈代码依赖只能指向内圈,内圈无需知道外圈任何情况。
红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
又名“端口适配器架构”。
红圈内的核心业务逻辑(应用程序和领域模型)与外部资源(包括APP、Web应用以及数据库资源等)完全隔离,仅通过适配器交互。它解决了业务逻辑与用户界面的代码交错问题,很好实现前后端分离。六边形架构各层的依赖关系与整洁架构一样,都是由外向内依赖。
系统分为内六边形和外六边形:
该架构的一个端口可能对应多个外部系统,不同外部系统也可能使用不同适配器,由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户形式使用。 现在,很多声称使用分层架构的团队实际上使用的是六边形架构。这是因为 很多项目都使用了某种形式的依赖注入。并不是说依赖注入天生就是六边形架 构,而是说使用依赖注入的架构自然地具有了端口与适配器风格。
虽然DDD分层架构、整洁架构、六边形架构的架构模型表现形式不同,但设计思想正是微服务架构高内聚低耦合原则的完美体现,而它们身上闪耀的正是以领域模型为中心的设计思想。
红色实线边框用于将核心业务逻辑与外部应用、基础资源进行隔离。
红框内部主要实现核心业务逻辑,但核心业务逻辑也有差异,有属于领域模型,有属于面向用户的用例和流程编排能力。按这种功能差异,在这三种架构划分了应用层和领域层,承担不同业务逻辑。
领域层实现面向领域模型,实现领域模型的核心业务逻辑,属原子模型,需保持领域模型和业务逻辑稳定,对外提供稳定的细粒度领域服务,所以是架构核心。
应用层实现面向用户操作相关的用例和流程,对外提供粗粒度API服务。适配前台应用和领域层,接收前台需求,随时做出响应和调整,尽量避免将前台需求传到领域层。应用层作为配速齿轮位于前台应用和领域层间。
这三种架构都考虑了前端需求的变与领域模型的不变。需求变幻无穷,但变化总是有矩可循的,用户体验、操作习惯、市场环境以及管理流程的变化,往往会导致界面逻辑和流程的多变。但核心领域逻辑基本不大变,领域模型相对稳定,用例和流程则会随外部需求而随时调整。
架构模型通过分层控制需求变化从外到里对系统影响,从外向里受需求影响逐步减小。面向用户的前端可以快速响应外部需求进行调整和发布,应用层通过服务组合和编排来实现业务流程的快速适配上线,减少传到领域层的需求,使领域层保持长期稳定。
这样设计的好处,可保证领域层核心业务逻辑不会因外部需求和流程的变动而调整。
中台本质是领域的子域,它可能是核心域,也可能是通用域或支撑域。通常大家认为阿里的中台对应DDD的通用域,将通用的公共能力沉淀为中台,对外提供通用共享服务。
中台作为子域还可以继续分解为子子域,在子域分解到合适大小,通过事件风暴划分限界上下文以后,就可定义微服务,微服务用来实现中台能力。
中台需考虑能力的共享和复用。 要建立中台内所有限界上下文的领域模型,DDD建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界(微服务)划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型,最终影响到微服务的拆分和项目落地。
微服务设计要有分层思想。 保证领域层的纯洁和领域逻辑的稳定,避免污染领域模型。不要把领域模型的业务逻辑放在应用层,这样会导致应用层过大,领域模型会失焦。实在无法避免,可以引入防腐层,进行新老系统的适配和转换,过渡期完成后,可直接将防腐层代码抛弃。
。而有的则是某个职责单一的中台微服务,企业级的业务流程需要将多个这样的微服务组合起来才能完成,这是企业级中台微服务。两类微服务由于复杂度不一样,集成方式也会有差异。
可与前端应用集成,一起完成特定业务。 项目级微服务的内部遵循分层架构模型即可。领域模型的核心逻辑在领域层实现,服务的组合和编排在应用层实现,通过API网关为前台应用提供服务,实现前后端分离。但项目级微服务可能会调用其它微服务,你看在下面这张图中,比如某个项目级微服务B调用认证微服务A,完成登录和权限认证。
通常项目级微服务之间的集成,发生在微服务的应用层,由应用服务调用其它微服务发布在API网关上的应用服务。你看下图中微服务B中红色框内的应用服务B,它除了可以组合和编排自己的领域服务外,还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到API网关供前端调用,这样前端就可以直接访问自己的微服务了。
可在中台微服务上增加一层,位于红色边框,负责跨中台微服务的服务组合和编排,以及微服务之间的协调,还可完成前端不同渠道应用的适配。 再将它的业务范围扩大一些,可做成一个面向不同行业和渠道的服务平台。
借用BFF(服务于前端的后端,Backend for Frontends)词。BFF微服务与其它微服务存在较大的差异,就是它没有领域模型,因此这个微服务内也不会有领域层。BFF微服务可以承担应用层和用户接口层的主要职能,完成各个中台微服务的服务组合和编排,可适配不同前端和渠道的要求。
传统以数据为中心的设计模式,应用会对数据库、缓存、文件系统等基础资源产生严重依赖。 一旦更换基础资源就会对应用产生很大的影响,因此需要为应用和资源解耦。 在微服务架构中,应用层、领域层和基础层解耦是通过仓储模式,采用依赖倒置的设计方法来实现的。在应用设计中,我们会同步考虑和基础资源的代码适配,那么一旦基础设施资源出现变更(比如换数据库),就可以屏蔽资源变更对业务代码的影响,切断业务逻辑对基础资源的依赖,最终降低资源变更对应用的影响。
DDD分层架构、整洁架构、六边形架构都是以领域模型为核心,实行分层架构,内部核心业务逻辑与外部应用、资源隔离并解耦。