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)的实现
形三
这是张逸老师课程的又一形态
六边形架构仅仅区分了内外边界，提炼了端口与适配器角色，并没有规划限界上下文内部各个层次与各个对象之间的关系；而整洁架构又过于通用，提炼的是企业系统架构设计的基本规则与主题。因此，当我们将六边形架构与整洁架构思想引入到领域驱动设计的限界上下文时，还需要引入分层架构给出更为细致的设计指导，即确定层、模块与角色构造型之间的关系
这是老师最新总结的菱形对称架构
南向网关引入了抽象的端口来隔离内部领域模型对外部环境的访问。这一价值等同于上下文映射的防腐层（Anti-Corruption Layer，简称为 ACL） 模式，只是它扩大了防腐层隔离的范围
形态四
该架构由端口和适配器组成，所谓端口是应用的入口和出口，在许多语言中，它以接口的形式存在
Martin Fowler将“封装访问外部系统或资源行为的对象”定义为网关（Gateway），在限界上下文的内部架构中，它代表了领域层与外部环境之间交互的出入口，即：
gateway = port + adapter
这个形态，简单入里，算是菱形对称架构的简易形，甚至可以说是菱形的初形
driving adapter + domain + driven adapter
总结
形态之多，背后的理论支撑之丰富，可见DDD的博大精深，谁能说是正宗，就算是Eric Evans都要怀疑人生，但不迷信，没有银弹。自己实践的才是最合适
