这十年，我所经历的领域驱动设计（DDD）

笔者2011年入行时，运气好，遇到了我的恩师simon杨。

当时，我们几个还不知道什么叫SSH（Spring、Struts、Hibernate）的毕业生和一个高级程序员基于DDDLib就开始实践领域驱动设计。现在想想还是觉得不可思议。一毕业就开始接触这门DDD技艺。

我记得当时simon杨经常谈如何利用抽象、解耦，在不增加复杂性的同时实现简单性、一致性、灵活性、可扩展性。至于如何实现CRUD，那是具体实现的问题，可以放在最后做。当他谈到某个精妙的设计时，眼神里满是光。

在他的教导下，我就开始似懂非懂地读《领域驱动设计》、《企业应用架构模式》、《敏捷软件开发——原则、模式与实践》等这些高层设计类的书籍。

image.png

也许你会说，对于一个刚毕业的人学习这些“高层”设计，是不是太早了，毕竟你连CRUD都还不熟练。

在我工作10年之后看来，越早学习这些，越好。当你习惯使用CRUD的思维方式来看所有的问题时，你的思维方式已经固化，是很难接受DDD这套思维方式的。我尝试过说服不同工作经验的人使用DDD，无果。

2013年，在国内，也只有Jdon网站讨论DDD。而我们已经跟着simon杨在项目上实践DDD两年了。

2014年左右，为了验证了我是否真的理解DDD，我利用一次比赛的机会采用DDD的方式设计了一个BlackJack的游戏的核心。到此，我才算是对DDD有了一个更深入的理解。

但是，在2014年以后到现在的2021年，我就再也没有接触过DDD的项目了。而我，只能在自己的工作内容范围内实践，比如某个功能、某个模块。

值得说的是，我最近3年做的是DevOps相关的工作，但是DDD的思维方式依然能帮助我很好的完成工作。

比如在实现流水线时，将构建工具逻辑与流水线流程逻辑解耦、在设计 版本号时，将构建工具本身的版本号与流水线流程生成的版本号分离。

如果你不熟悉DevOps也没有关系，你只需要知道DDD贯穿着整个系统设计的每一个细节。

现在市场上把DDD吹得很高大上，似乎只有在架构上做DDD，才叫DDD。又或者非得和微服务关联在一起，才叫DDD。

其实不然，DDD的原意是领域驱动设计。只要你是使用领域知识来驱动你的设计，这个设计可以是方法级别的设计、类级别的设计、前端UI的设计等一切设计，你都可以叫DDD。

也许，这样的话听起来就像“色即是空，空即是色”一样让人不知所云。

没办法，10年了，我也没有找到非常好的让人一下就懂这种思维方式的方法。

如果非得要我介绍一下DDD的思维是什么，我觉得就是：不停地问问题是什么，解决方案是什么。然后优先从问题域着手设计。在确定问题域设计得差不多了，才开始实现解决方案。

这里要提个问，如果拿到一个需求时，先设计MySQL的表结构，再根据表结构导出类。这样的方式符合DDD的思维方式吗？如果不符合，与DDD的思维方式有什么区别？

最后，我想说的是《领域驱动设计》我读过3遍了，也实践这么多年了，我依然记不清“战略设计”、“柔性设计”等这些术语的准确定义。我也建议各位不要去记那些术语的定义，更不要去争论那些术语的定义，而是要从DDD的原意开始去理解DDD。也就是每当遇到一个术语，你就提问：它是如何帮助你领域驱动设计的呢。

欢迎关注公众号：持续交付实践指南

往期好文：

• 我是如何做软件工程化的

• 可落地的云原生应用规范