领域驱动设计--菱形架构(四)

本文主要是介绍领域驱动设计--菱形架构(四)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在实施领域驱动设计的过程中，限界上下文（Bounded Context）扮演了关键角色：它既是维护领域模型完整性与一致性的重要边界，又是系统架构的重要组成部分。随着社区对限界上下文的重视，越来越多的人开始尝试将更多的架构实践与限界上下文融合在一起，创造出符合领域驱动设计的架构模式。

Eric Evans 在领域驱动设计中引入了分层架构（Layered Architecture），目的是希望能够分离领域，这意味着该模式本身是作用在整个系统层次。Vaughn Vernon 在《实现领域驱动设计》一书中，将 Alistair Cockburn 提出的六边形架构（Haxagonal Architecture）引入到领域驱动设计中，并将其与限界上下文结合在一起，清晰地体现了它内部的视图。这一模式的引入，实际上代表着限界上下文在架构中的核心地位。

限界上下文改变了系统架构的逻辑视图，领域层的抽取则意味着领域对设计的驱动力，二者的结合可以形成一种新的架构风格，我将其称之为“领域驱动架构（Domain Driven Architecture）”。该架构风格建立了以领域为核心驱动力，以整洁架构为指导原则，将整个系统分解为多个限界上下文，并通过上下文映射（Context Map）表现限界上下文之间的协作关系以及系统与外部环境之间关系。

这一架构风格将整个系统的架构分为两个层次：

系统层次
领域层次

系统层次的架构以限界上下文为核心，从纵向维度根据业务能力纵向切分形成限界上下文，然后从横向维度提炼出由限界上下文组成的价值层（Value-Added Layer）。

领域层次的架构针对限界上下文内部以领域为核心进行关注点分解，形成由内部领域模型与外部网关组成的内外分层架构。

本文提出的菱形对称架构（Rhombic Symmetric Architecture）主要针对领域层次的架构，借鉴了六边形架构、分层架构、整洁架构的知识，并结合了领域驱动设计的元模型，使其能够更好地运用到限界上下文的架构设计中。因此，本文会依次介绍六边形架构、整洁架构与分层架构，由此再引出我定义的菱形对称架构。

说明：由于菱形又可以表示为diamond，故而该架构模式也可以称之为“钻石架构”，简称 diamond。我在 GitHub 上建立了名为diamond的代码库，提供了本文案例的 Demo 代码，也清晰地展现了限界上下文的代码结构。

六边形架构

六边形架构（Hexagonal Architecture）又被称之为端口适配器（Port and Adapter），由 Alistair Cockburn 提出，他的定义为：“无论是被用户、程序、还是自动化测试或批处理脚本驱动，应用程序（Application）都能一视同仁地对待，最终使得应用程序能独立于运行时设备和数据库进行开发与测试。”

包含了领域逻辑的应用程序放在六边形的边界内，它与外界的通信只能通过端口与适配器进行。端口存在两个方向：入口和出口。与之相连的适配器自然也存在两种适配器：入口适配器（Inbound Adapter，又可称为 Driving Adapter）和出口适配器（Outbound Adapter，又可称为 Driven Adaptor）。入口适配器负责处理系统外部发送的请求，也就是驱动应用程序运行的用户、程序、自动化测试或批处理脚本会向入口适配器发起请求，适配器将该请求适配为符合内部应用程序执行的输入格式，转交给端口，再由端口调用应用程序。出口适配器负责接收内部应用程序通过出口端口传递的请求，对其进行适配后，向位于外部的运行时设备和数据库发起请求。

显然，从内外边界的视角观察端口与适配器的协作，整个过程如下图所示：

在 Cockburn 对六边形架构的初始定义中，应用程序处于六边形边界之内，它封装了支持业务功能的领域逻辑。入口端口与出口端口放在六边形边界之上，前者负责接收外部的入口适配器转换过来的请求，后者负责发送应用程序的请求给外部的出口适配器，由此可以勾勒出一个清晰的六边形：

我们说限界上下文是在特定知识语境下的业务能力的体现，这一业务能力固然以领域模型为核心，却必须通过与外部环境的协作方可支持其能力的实现，因此限界上下文的边界实则包含了对驱动它运行的入口请求的适配与响应，也包含了对外部设备和数据库的访问。若要将限界上下文与六边形架构结合起来，就需要将入口适配器和出口适配器放在限界上下文的边界之内，从而构成一个外部的六边形：

六边形架构清晰地勾勒出限界上下文的两个边界：

外部边界：通过外部六边形展现，是限界上下文的业务边界，当然，同时也可能是限界上下文的工作边界与应用边界。我将此六边形称之为“应用六边形”。
内部边界：通过内部六边形将领域单独抽离出来，隔离了业务复杂度与技术复杂度。我将此六边形称之为“领域六边形”。

以预定机票场景为例，用户通过浏览器访问订票网站，向订票系统发起订票请求。根据六边形架构的规定，前端 UI 位于应用六边形之外，属于驱动应用程序运行的起因。订票请求发送给以 RESTful 契约定义的资源服务ReservationResource，它作为入口适配器，介于应用六边形与领域六边形的边界之内。ReservationResource在接收到以 JSON 格式传递的前端请求后，将其转换（反序列化）为入口端口ReservationAppService需要的请求对象。

入口端口为应用服务，位于领域六边形的边界之上。当它在接收到入口适配器转换后的请求对象后，调用位于领域六边形边界内的领域服务TicketReservation，执行领域逻辑。

在执行订票的领域逻辑时，需要向数据库添加一条订票记录。这时，位于领域六边形边界内的领域模型对象会调用出口端口ReservationRepository。出口端口为资源库，位于领域六边形的边界之上，定义为接口，真正访问数据库的逻辑则由介于应用六边形与领域六边形边界内的出口适配器ReservationRepositoryAdapter实现。该实现访问了数据库，将端口发送过来的插入订票记录的请求转换为数据库能够接收的消息，执行插入操作。

该领域场景在六边形架构中的体现为：

六边形架构中的端口是解耦的关键。入口端口体现了“封装”的思想，它既隔离了外部请求转换所必须的技术实现，如 REST 服务的反序列化机制与 HTTP 请求路由等基础设施功能，又避免了领域模型向外的泄露，因为端口公开的方法已经抹掉了领域模型的信息。出口端口则体现了“抽象”的思想，它通常需要定义为抽象接口，不包含任何具体的访问外部设备和数据库的实现。

显然，入口端口抵御了外部请求可能对当前限界上下文造成的侵蚀，因此，入口适配器与入口端口之间的关系是一个依赖调用关系；出口端口隔离了领域逻辑对技术实现以及外部框架或环境的依赖，因此，出口适配器与出口端口之间的关系是一个接口实现关系。二者的结合共同为限界上下文两个边界层次的松散耦合提供助力，最终保证了限界上下文的自治能力。