DDD之形

码农戏码

发布于 2021-03-23 11:25:42

7090

发布于 2021-03-23 11:25:42

文章被收录于专栏：DDD

DDD现在已然变成哲学，正因为是哲学，所以法无定法，到底怎么具体怎么实施，各显神通，心法固然重要，但心法有几人能真正领悟，一说就懂，一问就不会，一讨论就吵架；所以还是从外形看看，收集一些实践后的形态，由表入里，以形学形，慢慢品

看下面两个分层，左边是Vaughn Vernon 在《实现领域驱动设计》一书中给出了改良版的分层架构，他将基础设施层奇怪地放在了整个架构的最上面；右边就是DDD最标准的分层形态

形一

这是DDD专家张逸老师形态之一，除了controller在gateway中，其它还算常态

ecommerce

core
- Identity
- ValueObject
- Entity
- DomainEvent
- AggregateRoot
controllers
- HealthController
- MonitorController
application（视具体情况而定）
interfaces
- io
- telnet
- message
gateways
- io
- telnet
- message
ordercontext
- application
- interfaces
- domain
- repositories
- gateways
productcontext
- application
- interfaces
- domain

除了限界上下文自身需要的基础设施之外，在系统架构层面仍然可能需要为这些限界上下文提供公共的基础设施组件，例如对 Excel 或 CSV 文件的导入导出，消息的发布与订阅、Telnet 通信等。这些组件往往是通用的，许多限界上下文都会使用它们，因而应该放在系统的基础设施层而被限界上下文重用，又或者定义为完全独立的与第三方框架同等级别的公共组件。理想状态下，这些公共组件的调用应由属于限界上下文自己的基础设施实现调用。倘若它们被限界上下文的领域对象或应用服务直接调用（即绕开自身的基础设施层），则应该遵循整洁架构思想，在系统架构层引入 interfaces 包，为这些具体实现定义抽象接口

controller被放到了gateway中，包含远程调用，数据库；所有对外的接口都属于一种网关

形二

cola在github开源，作者模块与包划分，每个架构元素都很明确

controller

这是一个可选层，正如《分层架构》所讲，现在的框架都已经帮助从底层的具体HttpRequest转换成了requestDto，很多时候都是透传service，而像thrift类的框架，为了透明化入口，需要转换一下，

包

xxx.controller

client

二方库，里面存放RPC调用的DTO

包

xxx.api:存放应用对外接口

xxx.dto.domainmodel：数据传输的轻量级领域对象

xxx.dto.domainevent:数据传输的领域事件

application

应用层

包

xxx.service：接口实现的facade，没有业务逻辑，可以对应不同的adapter

xxx.event.handler:处理领域事件

xxx.interceptor:对所有请求的AOP处理机制

domain

领域层

包

xxx.domain:领域实现

xxx.service:领域服务，用来提供更粗粒度的领域能力

xxx.gateway:对外依赖的网关接口，包括存储、RPC等

infrastructure

基础层

包

xxx.config:配置信息相关

xxx.message:消息处理相关

xxx.repository:存储相关，gateway的实现类，主要用来做数据的CRUD操作

xxx.gateway:对外依赖网关接口(domain里面的gateway)的实现

形三

这是张逸老师课程的又一形态

六边形架构仅仅区分了内外边界，提炼了端口与适配器角色，并没有规划限界上下文内部各个层次与各个对象之间的关系；而整洁架构又过于通用，提炼的是企业系统架构设计的基本规则与主题。因此，当我们将六边形架构与整洁架构思想引入到领域驱动设计的限界上下文时，还需要引入分层架构给出更为细致的设计指导，即确定层、模块与角色构造型之间的关系