主要概念
既然是《实现DDD落地》就要先从技术讲起。我将由从理论到实现，从总体到细节逐步分享给大家，想交流的朋友可以在下方留言，我会及时回复。
DDD 的技术层面主要概念有：六边形架构，聚合设计、CQRS、事件溯源技术组成。
DDD 技术落地的困难之一在于多个不同方面的架构思想相互叠加给使用者带来的困惑。我们先对各个概念进行一步步的介绍。
六边形架构
六边形架构是对传统的MVC架构思想的进化与升级， 主要改变我的代码结构。主要有用户接口层（userinterface）、领域层（domain）、应用层（application）、基础设施层（infrastructure）组成。六边形架构采用适配思想将输入端、应用逻辑、业务逻辑、存储端进行了有效的分离。系统可以更好的应对不同的输入端与存储设备，确保核心业务逻辑的稳定。
用户接口层：负责传输协议，传输数据格式的转换工作，是输入的接受者。这里可以对不同的传输协议进行分层如rest、grpc等，同时也可以对不同的输入与输出格式进行处理。
领域层：处理核心业务逻辑。 领域层最复杂，其中包含了聚合设计，CQRS ，事件溯源的设计思想。可以分为command、event、model、service、repository、factory等层。被应用层调用。这里有一个重要的设计原则：依赖倒置原则，面向接口编程，将实现放在基础设施层完成，降低核心业务对具体技术的依赖。
应用层：被用户层调用， 负责调用编排领域层service和外部服务， 管理分布式事务等应用问题。
基础设施层：负责解决具体的技术问题，领域层的接口实现，数据库操作实现，配置文件，中间件等其他内容。
项目结构
userinterface # 用户接口层
handler # 外部事件接受层
rest # restful协议
contrller # rest的控制器
dto # 数据传输层
request # contrller方法输入数据
response # contrller方法输出数据体
grpc # grpc协议层
....
application # 应用层
bound # 外部服务对接层
order # 外部服务名称
handler # 外部事件接收层
service # 外部服务
dto #
internal # 领域内部
appservice # 应用服务
domain # 领域层
command # 命令
event # 领域事件
model # 领域模型
service # 领域服务
repository # 仓储层接口
factory # 工厂类，进行数据转换，如将command转成event
infrastructure # 基础设施层
repositoryimpl # 仓储层实现
configs # 配置类
... # 其他
以上是一个基础的项目结构，当也CQRS，事件溯源，部署方式结合时，会有更详细的划分。
CQRS架构
CQRS是命令查询职责分离模式。是一种读写分离模式。
命令端只负责写入操作，只可返回实体Id， 写数据的同时要发布领域事件到消息总线中，查询端异步接收进行数据更新。
查询端根据数据展示需要，编写专属的数据结构（读实体）进行数据展示。查询端需求从消息总线中订阅领域事件，对读实体进行更新。查询端可以采用多种数据库进行数据存储。
从落地部署时，可以将命令端与查询端可以写成两个服务微服务， 这样可以更好的调整pod数量。
逻辑图
