文章链接
前导
领域驱动设计（Domain Driven Design，简称DDD）是业内主导的业务工程理论。它在各中权威人士被广泛讨论，但实际落地的具体实践缺相对较少。有人认为DDD是一个听起来高深，缺缺乏实践指导，在各大佬口中被广泛提及但是很少有下场谈具体实现的。DDD是一种听起来高大上，谈起来空洞的方法论，这里我基于代码工程角度抛砖引玉，整理出我的认识。本次我使用GO语言作为工程目录参考，后续会补充Java
DDD 是一种方法论，是“分治”思想的更详细的描述，将一个复杂的系统拆分成一个个尽可能垂直正交的小问题域，让每个问题各自约束自己的职责，从而实现整体框架的简洁清晰。DDD 本质还是遵循高内聚、低耦合的设计原则；根SOLID原则遥相呼应。DDD的战略设计是站在一个更高更抽象的角度拆分问题，战术设计原则是指导具体的落地实现细节。如果对DDD接触不深的话可以参考DDD理论基础。下面简单列一下常见的工程代码的设计方法和特点。
| 设计方法 | 出发点 | 关注点 | 模型 | 所处层 | 技术方案 | 使用场景 |
|---|---|---|---|---|---|---|
| 数据驱动设计 | 从数据存储方案出发 | 怎么存 | 实体关系建模，贫血模型，只有数据 | 基础设施层 | 根据存储方案密关联 | 简单的业务场景CRUD |
| 服务驱动设计 | 从服务提供的资源和行为能力出发 | 提供什么服务 | 接口对象建模，贫血模型，只有数据 | 应用层 | 不关注实体实现方案 | 简单的业务场景，API服务 |
| 领域驱动设计 | 一切围绕着领域知识进行建模 | 领域划分和建模 | 领域对象建模，充血模型，包括数据和方法 | 领域层 | 不考虑存储方式（技术实现） | 复杂业务场景 |
数据驱动设计，采用的是事物脚步的写法，这种写法适合简单、初期项目；随着业务迭代复杂会出现逻辑散乱、职责不清、重复代码、无法单测等诸多问题，常常会出现改漏导致的Bug或事故。
工程代码结构
工程代码按照clean arch 架构来进行分层，如下图
分层概述
Domain是践行面向对象编程，为当前类（go是结构体）负责，按照对象能力方式组织代码。
UseCase是面向过程的编程，为场景能力负责，
