领域驱动设计：如何从0搭建DDD系统 | IT宅-帅旋的专业知识分享

领域驱动设计：如何从0搭建DDD系统

发布于 2021-08-15 | 更新于 2024-05-16

DDD

6

CQRS

6

1 DDD项目结构

基于以上DDD架构的思想，我们可以把我们的系统划分为如下层次结构，具体代码结构可以如下，仅供参考：

itzhai-service
|-- itzhai-code                 公共模块代码
|    | 
|    |-- java 
|         |-- domain            领域通用类
|         |-- utils             工具类
|   
|-- itzhai-boot                 启动模块
|    | 
|    |- java        
|    |    |- Application         系统启动类
|    |    |- config              配置类
|    |- resources 
|        |- application.yml      配置文件
|        |- ...
| 
|- itzhai-module1                 系统子域模块
|    | 
|    |- java 
|         |- application         应用层
|         |    |- command        命令
|         |    |- handler        命令处理类
|         |    |- query          查询处理类
|         |- domain              领域层
|         |    |- factory        领域工厂
|         |    |- model          领域模型
|         |    |- service        领域服务
|         |    |- specification  规格校验类
|         |    |- repository     仓储接口
|         |    |- external       外部接口(防腐层)
|         |- infrastructure      基础设施层
|         |    |-repository      仓储实现类
|         |        |-po          持久层对象
|         |        |-mapper      持久层对象与领域对象的转换工具类
|         |        |- dao        数据访问接口
|         |    |- external.impl  被动适配器，适配外部接口
|         |- activeadapter       主动适配器，提供rpc，rest等接口
|   
|- itzhai-module2                 系统子域模块
|
...
|- pom.xml                        

一旦确定项目结构之后，就需要作为规范，让其他同事遵守。这些目录就像是一个一个的收纳盒，可以把代码放到合理的位置，同时，由于该目录遵循整洁架构思想，保证了核心领域代码与外部接口或者基础设施的解耦。

2 DDD设计要素

在DDD系统设计与开发过程中，关键的要点：

• 像《领域驱动设计》一书中讲的那样，跟系统所有的参与者(产品、业务领域专家、运营、开发、测试等)形成一套通用语言，这套语言既是在你的代码的类名、方法名等的命名来源；
• 你应该首先在需求中分析领域模型，设计领域模型的边间与核心逻辑，以及领域的聚合设计，而不是直接上来就写MySQL建表脚本，创建表结构；
• 尝试在流程图中加上泳道，按照领域模型划分泳道，而不是基于已有的微服务，这样可以避免写出事务过程式的脚本代码；也许序列图更能够帮助到你理清交互关系中的技术细节。

3 DDD不是银弹^[1]

同时，你需要认清这个事实，避免让DDD在项目中遭遇失败：

• 设计模式不是DDD的关键：DDD 与其说是软件设计模式，不如说是通过协作解决问题；
• DDD不是以代码为中心的：DDD不会帮你写出优雅的代码，代码只是DDD的产物；
• DDD不是一个框架：DDD没有固定的框架，它只是一种设计思想，对于同一个DDD项目的不同限界上下文，你完全可以使用不同的架构风格；
• 并不是所有的系统适用DDD：那些具有很少问题域的系统，也就是业务很简单的系统，不适合使用DDD，因为使用了之后反而会拖慢系统进程。

一般我们看到的比较成功的DDD项目的的代码都是是经过几次迭代之后才产生的，所以在探索业务阶段不适合DDD…

如果你看到了一个DDD的Demo程序之后，就匆忙的想立刻依葫芦画瓢把自己的业务系统改造成DDD，那和可能会面临很多没有考虑到的问题，因为一般Demo程序都很简单，并不能对业务开发过程中的所有问题都提出解决方案。

有没有完美的DDD框架？据我所知，并没有，DDD最重要的是理解业务，达成共识，然后基于业务通过各种方法构建领域模型。业务之外，你可以做的就是提供一个规范，让大家按照规范填代码，好让代码朝着整洁架构方向迭代。

朋友们，都学会了吗？现在，让我们开始动手，实现我们自己的DDD系统吧。

References

---

1. DOMAIN-DRIVEN DESIGN. Retrieved from https://danysk.github.io/Course-Laboratory-of-Software-Systems/21-ddd-intro/#/ ↩︎

领域驱动设计：领域模型是如何建立的？

洞悉Redis技术内幕：缓存，数据结构，并发，集群与算法...