DDD Lite

DDD 畛域驱动设计的小名大家应该都有所耳闻，然而理论我的项目残缺落地 DDD 的很少。因为 DDD 概念繁冗，畛域、子域、外围子域、通用子域、实体、值对象、畛域服务、应用服务、畛域事件、上下文等一大堆概念，间接把人绕晕，对应到理论业务模型时，横看成岭侧成峰，开发人员外部都难以达成统一。

因为 DDD 设计之初指标是作为简单软件解决之道，但咱们大部分利用并没有那么简单，一个简略的利用应用这么一套简单的概念，有点画蛇添足。在微服务时代，设计准则就是依据畛域划分上下文，单体利用复杂度大大降低，微服务须要一种精简的架构。

这里我提出轻量级 DDD 架构：DDD Lite，让其更好的符合微服务。

分层架构在 MVC 中就被宽泛采纳，DDD 中也有四层架构、五层架构、六边形架构等多种流派。DDD Lite 采纳较为简单的四层架构，自上而下为：

• Interface
• Service
• Model
• Infrastructure

分层

Interface

接口层。

对外提供 HTTP，RPC 等接口，参数校验、编解码等逻辑在本层解决，业务状态码、对外数据结构在本层定义。

Service

服务层。

次要业务逻辑层，调用 Model 层 Repository 接口实现畛域业务逻辑，事务组装。一个 Service 对应一个畛域，畛域是指类似业务逻辑的归类。一个微服务个别只有一到两个 Service，不宜过多。

Model

数据模型层。

定义数据结构，以及数据模型对应的 Repository 接口，但不蕴含具体实现。多个相干 Model 组成畛域，此处对畛域进行简化，不再纠结于子域、实体、值对象等细粒度概念。围绕 Model 定义 Repository 接口，不掺杂业务逻辑，供 Service 层调用，不便在 Service 层组成事务。

Repository pattern

这里独自讲一下 Repository 设计模式，这是设计好数据模型的重中之重。

Repository 模式即是将对数据结构的操作形象成接口，将业务逻辑（business logic）和数据处理（data access）拆散，退出了一个形象层。

有了 Repository 接口，依赖就从具体变成形象，和 DB 等根底层依赖解耦，不便施行 TDD（测试驱动开发）。

Repository 接口应该放弃细粒度，设计得足够通用，缩小业务属性，不便复用。

Infrastructure

基础设施层。

实现 Model 层 Repository 接口，对接 DB、MQ 等数据长久化，或者 RPC 近程调用后端服务。

同时也能够提供 Repository fake 实现，供 Service 层单元测试应用。

总结

DDD 中的很多方法论，其中大部分大家在我的项目工程中都见过或者实际过。但 DDD 要求的前提过于现实，比方什么领域专家，通用语言等前提，在民工式麻利开发，需要朝令夕改，996 减速的大环境下，过于空幻，难以落地。所以咱们没必要全盘照搬，应该就地取材，去取精髓去其糟粕，提炼出适宜本人的利用架构。DDD Lite 对 DDD 设计模式进行了简化，是作者对 DDD 的实践结合实际工程教训的一些总结和思考。

DDD Lite 架构仅为集体了解，如有浅见，欢送交换。

残缺我的项目代码：win5do/go-microservice-demo (github.com)

Reference

DDD 分层架构：https://www.yyang.io/2015/12/31/DDD-and-Layered-Architecture/

国外大佬提出的 DDD Lite 架构：https://threedots.tech/post/ddd-lite-in-go-introduction/

国内大佬残缺遵循 DDD 设计的 Go demo，集体感觉略显繁琐：https://github.com/agiledragon/ddd-sample-in-golang