文章链接

1. 领域驱动设计（DDD）笔记（一）基本概念-CSDN博客
2. 领域驱动设计（DDD）笔记（二）代码组织原则-CSDN博客
3. 领域驱动设计（DDD）笔记（三）后端工程架构-CSDN博客

前导

领域驱动设计（Domain Driven Design，简称DDD）是业内主导的业务工程理论。它在各中权威人士被广泛讨论，但实际落地的具体实践缺相对较少。有人认为DDD是一个听起来高深，缺缺乏实践指导，在各大佬口中被广泛提及但是很少有下场谈具体实现的。DDD是一种听起来高大上，谈起来空洞的方法论，这里我基于代码工程角度抛砖引玉，整理出我的认识。本次我使用GO语言作为工程目录参考，后续会补充Java

DDD 是一种方法论，是“分治”思想的更详细的描述，将一个复杂的系统拆分成一个个尽可能垂直正交的小问题域，让每个问题各自约束自己的职责，从而实现整体框架的简洁清晰。DDD 本质还是遵循高内聚、低耦合的设计原则；根SOLID原则遥相呼应。DDD的战略设计是站在一个更高更抽象的角度拆分问题，战术设计原则是指导具体的落地实现细节。如果对DDD接触不深的话可以参考DDD理论基础。下面简单列一下常见的工程代码的设计方法和特点。

设计方法	出发点	关注点	模型	所处层	技术方案	使用场景
数据驱动设计	从数据存储方案出发	怎么存	实体关系建模，贫血模型，只有数据	基础设施层	根据存储方案密关联	简单的业务场景CRUD
服务驱动设计	从服务提供的资源和行为能力出发	提供什么服务	接口对象建模，贫血模型，只有数据	应用层	不关注实体实现方案	简单的业务场景，API服务
领域驱动设计	一切围绕着领域知识进行建模	领域划分和建模	领域对象建模，充血模型，包括数据和方法	领域层	不考虑存储方式（技术实现）	复杂业务场景

数据驱动设计，采用的是事物脚步的写法，这种写法适合简单、初期项目；随着业务迭代复杂会出现逻辑散乱、职责不清、重复代码、无法单测等诸多问题，常常会出现改漏导致的Bug或事故。

工程代码结构

工程代码按照clean arch 架构来进行分层，如下图

分层概述

Domain是践行面向对象编程，为当前类（go是结构体）负责，按照对象能力方式组织代码。

UseCase是面向过程的编程，为场景能力负责，