畛域驱动架构篇—菱形对称架构
畛域驱动设计中,对于架构格调有一个指导思想:不同的限界上下文,依据其畛域模型和业务特色,能够选用不同的架构格调。
在传统的分层架构与畛域驱动理念相结合的过程中,产生了多种架构格调:六边型架构、整洁架构、微服务架构等。本文是依据对对 IT 文艺工作者张逸老师的相干 Chat 浏览和思考整顿而得。
前言
菱形对称架构(Rhombic Symmetric Architecture)次要针对畛域档次的架构,借鉴了六边形架构、分层架构、整洁架构的常识,并联合了畛域驱动设计的元模型,使其可能更好地使用到限界上下文的架构设计中。
架构演进之路
六边型架构
六边型架构的特点就是:在满足整洁架构思维的同时,更加关注内层与外层本人与内部资源之间的通信实质
对于外界每种类型都有一个适配器与之对应:音讯适配器,REST 适配器,SOAP 适配器,长久化适配器
通过内外两个六边形的不同边界清晰地展示了了畛域与技术的边界(蓝色是畛域,灰色是技术)
- 端口:咱们能够把端口看成是具体的协定
- 适配器:看成是具体的通信垂直技术,如:Servlet、REST、JPA
- 利用:用例级别的业务逻辑,体现了一个业务场景
- 畛域模型:零碎级别业务逻辑,多个服务和聚合形成一个用例
六边型架构中,端口是解耦的要害:入口隔离了内部申请和技术实现细节;进口隔离了数据长久化和内部拜访设施
六边型架构的业务 (预约机票) 示例:
- ReservationResource:订票申请发送给以 RESTful 契约定义的资源服务,它作为入口适配器,介于利用六边形与畛域六边形的边界之内,在接管到以 JSON 格局传递的前端申请后,将其转换(反序列化)为入口端口 ReservationAppService 须要的申请对象
- ReservationAppService:入口端口为应用服务,位于畛域六边形的边界之上。当它在接管到入口适配器转换后的申请对象后,调用位于畛域六边形边界内的畛域服务 TicketReservation
- TicketReservation:订票的畛域逻辑
- ReservationRepository:进口端口为资源库,位于畛域六边形的边界之上,定义为接口
- ReservationRepositoryAdapter:真正拜访数据库的逻辑则由介于利用六边形与畛域六边形边界内的进口适配器,该实现拜访了数据库,将端口发送过去的插入订票记录的申请转换为数据库可能接管的音讯,执行插入操作
整洁架构
整洁架构的模型是一个相似内核模式的内外层构造,它具备以下特点:
- 1 越凑近核心,档次越高
- 2 由外到内:框架与驱动程序 –》接口适配器 –》利用级业务逻辑 –》零碎级业务逻辑
- 3 源码中依赖关系必须指向同心圆内层,从外到内
咱们能够在整洁架构上失去很多值得回味的设计思维:
- 不同档次的组件其变动频率也不雷同,引起变动的起因也不雷同(合乎高内聚低耦合设计思维)
- 档次越靠内组件依赖越少,处于外围业务实体没有任何依赖(畛域模型和技术完满解耦)
- 档次越靠内组件与业务关系越亲密,专属于特定畛域的内容,很难造成通用的框架(畛域构建出了壁垒)
在这个架构中,外层圆代表的是机制,内层圆代表的是策略;机制和具体的技术实现无关,容易受到外部环境变动;策略与业务无关,封装了最外围畛域模型,最不容易受到外界环境变动的影响
六边形架构仅仅辨别了内外边界,提炼了端口与适配器角色,并没有布局限界上下文外部各个档次与各个对象之间的关系;而整洁架构又过于通用,提炼的是企业零碎架构设计的根本规定与主题。因而,当咱们将六边形架构与整洁架构思维引入到畛域驱动设计的限界上下文时,还须要引入分层架构给出更为粗疏的设计领导,即确定层、模块与角色构造型之间的关系。
经典分层架构
分层架构是使用最为宽泛的架构模式,简直每个软件系统都须要通过层(Layer)来隔离不同的关注点(Concern Point),以此应答不同需要的变动,使得这种变动能够独立进行。
- 用户界面层:负责向用户展示信息和解释用户命令。蕴含 web 端 UI 界面、挪动端 UI 界面、第三方服务等。
- 应用层:很薄的一层,用来协调利用的流动,它不蕴含业务逻辑,它不保留业务对象的状态。在畛域设计中,它其实是一个外观(Facade),个别是供其余界线上下文根底设置层中 controller 调用。
- 畛域层:本层蕴含畛域的信息,是业务软件的外围所在。在这里保留业务对象的状态,对业务对象状态的长久化被委托给根底设置层。它蕴含畛域设计中的:聚合、值对象、实体、服务、资源接口等。
- 根底设置层:不要简略的了解为物理上的一层,它作为其余层的撑持库而存在。它提供了层间的通信,实现对业务对象的长久化。个别蕴含:网络通讯、资源实现(数据库长久化实现)、异步音讯服务、网关、controller 管制等。
菱形对称架构
菱形对称架构交融了分层架构和六边型架构的思维。
对六边型进行分层映射
- 入口适配器:响应边界外客户端的申请,须要实现过程间通信以及音讯的序列化和反序列化,这些性能皆与具体的通信技术无关,故而映射到基础设施层
- 入口端口:负责协调内部客户端申请与外部应用程序之间的交互,恰好与应用层的协调能力相配,故而映射到应用层
应用程序:承当了整个限界上下文的畛域逻辑,蕴含了以后限界上下文的畛域模型,毫无疑问,应该映射到畛域层 - 进口端口:作为一个形象的接口,封装了对外部设备和数据库的拜访,因为它会被应用程序调用,遵循整洁架构思维,也应该映射到畛域层
- 进口适配器:拜访外部设备和数据库的真正实现,与具体的技术实现无关,映射到基础设施层
冲破分层架构
分层架构仅仅是对限界上下文的逻辑划分,在编码实现时,逻辑层或者会以模块的模式体现,然而也可能将整个限界上下文作为一个模块,每个层不过是命名空间的差别,定义为模块内的一个包。不论是物理拆散的模块,还是逻辑拆散的包,只有能保障限界上下文在六边形边界的爱护下可能维持内部结构的清晰,就能升高架构侵蚀的危险。
根据整洁架构遵循的“稳固依赖准则”,畛域层不能依赖于外层。因而,进口端口只能放在畛域层。事实上,畛域驱动设计也是如此要求的,它在畛域模型中定义了资源库(Repository),用于治理聚合的生命周期,同时,它也将作为形象的拜访内部数据库的进口端口。
将资源库放在畛域层确有论据佐证,毕竟,在抹掉数据库技术的实现细节后,资源库的接口办法就是对聚合畛域模型对象的治理,包含查问、批改、减少与删除行为,这些行为也可视为畛域逻辑的一部分。
然而,限界上下文可能不仅限于拜访数据库,还可能拜访同样属于外部设备的文件、网络与音讯队列。为了隔离畛域模型与外部设备,同样须要为它们定义形象的进口端口,这些进口端口该放在哪里呢?如果仍然放在畛域层,就很难自圆其说。例如,进口端口 EventPublisher 反对将事件音讯公布到音讯队列,要将这样的接口放在畛域层,就显得不三不四了。假使不放在位于外部外围的畛域层,就只能放在畛域层内部,这又违反了整洁架构思维。
既然进口端口的地位如此难堪,而且很显著出和入不太对称,所以咱们罗唆就把出和入对称下,将端口和适配器对立掉,组合成“网关”。
下面的对称架构虽脱胎于六边形架构与畛域驱动设计分层架构,却又有别于二者。
对称架构北向网关定义的近程网关与本地网关同时承当了端口与适配器的职责,这实际上扭转了六边形架构端口 - 适配器的格调;畛域层与南北网关层的内外分层构造,以及南向网关规定的端口与适配器的拆散,又与畛域驱动设计的分层架构渐行渐远。
既然曾经扭转,就依据思维,从新形象下架构图
就失去了菱形对称架构,次要体现了南北网关的对称关系
菱形对称架构的组成
菱形架构其上下文的组成:
- 北向网关的近程网关:过程间通信
- 北向网关的本地网关:过程内通信
- 畛域层的畛域模型:畛域逻辑
- 南向网关的端口形象:各种资源库操作的形象借接口,能够被畛域层依赖,
- 南向网关的适配器实现:网关端口的实现,运行时通过依赖注入将适配器实现注入到畛域层
以六边型中的业务示例为例,改成菱形架构的话,其架构如下:
引入上下文映射
北向网关演变
北向网关和开放式主机服务很相似,然而职能更多,相当于开放式主机层,蕴含了近程服务和本地服务
- 近程服务:跨过程通信;蕴含资源(Resource)服务、供应者(Provider)服务、控制器(Controller)服务与事件订阅者(Event Subscriber)服务
- 本地服务:过程内通信;对应于应用层的应用服务
当内部申请从近程服务进入时,如果须要调用畛域层的畛域逻辑,则必须经由本地服务发动对畛域层的申请。此时的本地服务又表演了端口的作用,可认为近程服务是本地服务的客户端。
南向网关演变
南向网关引入了形象的端口来隔离外部畛域模型对外部环境的拜访,这一价值很等同于上下文映射中的防腐层,同样它也扩充了防腐层的性能
南向网关的端口分为:
- 资源库(repository)端口:隔离对外部数据库的拜访,对应的适配器提供聚合的长久化能力
- 客户端(client)端口:隔离对上游限界上下文或第三方服务的拜访,对应的适配器提供对服务的调用能力
- 事件发布者(event publisher)端口:隔离对外部音讯队列的拜访,对应的适配器提供公布事件音讯的能力
改良后的菱形对称架构
菱形对称架构去掉了应用层和基础设施层的概念,以对立的网关层进行概括,并以北向与南向别离体现了来自不同方向的申请。如此造成的对称构造突出了畛域模型的核心作用,更加清晰地体现了业务逻辑、技术性能与外部环境之间的边界。
资源库视为防腐层的端口与适配器,作为领域建模时的角色构造型,与场景驱动设计更好地联合,加强了畛域模型的稳定性。应用层被去掉之后,被弱化为凋谢主机服务层的本地服务,相当于从设计层面回归到服务外观的实质,也有助于解决应用服务与畛域服务之间的概念之争。
代码模型示例:
ohs 为凋谢主机服务模式的缩写,acl 是防腐层模式的缩写,pl 代表了公布语言;也能够应用北向(northbound)与南向(sourthbound)取代 ohs 与 acl 作为包名,应用音讯(messages)契约取代 pl 的包名。
转载地址:DDD 畛域驱动策略篇(6) 菱形对称架构