DDD为什么火了？

第一次听到DDD这个词是在几年前。乍一听感觉像TDD（测试驱动开发），但其实它们完全是两回事。当时看了一篇介绍DDD的博客，一大篇专业术语，搞得云里雾里，便没有深究下去了。

虽然DDD早在2003年就提出了，但一直没有火起来。直到最近两年才慢慢被大家熟知。深究其原因，我觉得有三方面：

  • 第一方面，DDD是解决复杂软件问题的，而之前的软件大多没有很复杂的逻辑，不用DDD也能玩得转；
  • 第二方面，DDD一直没有很好的落地指导，一直到《实现领域驱动设计》这本书的问世，为DDD的落地打开了大门；
  • 第三方面，国内没有团队去研究和布道，所以导致了解它的人本就不多。后来微服务大火以后，发现使用微服务有个痛点，就是如何去设计和拆分微服务。而DDD可以很好地解决这个问题，所以DDD乘着微服务的东风，也变得慢慢被大众熟知。
DDD到底是什么鬼？

DDD是当今业界唯一一个包含了从需求分析到落地的工具。DDD将重心放在业务上，从业务出发来设计代码，业务是DDD的中心。

DDD分为战略部分和战术部分，两者相辅相成。战略部分用于理解、梳理业务，找到核心业务，更好地划分系统（这也是DDD为什么可以用于指导微服务设计的原因）；战术部分用于落地到代码上，用代码来清晰地表示业务，代码如何分层、如何设计都有一套成熟的指导方案。

DDD可以比较好地解决复杂业务的软件开发，但DDD不是“银弹”，DDD也并不是一些死板的术语和规范。事实上，当今业界仍然在DDD的实践道路上探索前行。

银弹：某种便捷的开发技术，从而使某个项目的实施提高效率。

DDD同样不是唯一的选择，只是可以作为众多工具箱中的一个，在衡量成本和收益之后，可以取出来结合其它工具一起使用，为自己的业务服务，为自己设计更好的软件服务。

所以“领域”到底是什么？

所以“领域驱动设计”这句话后两个词很好理解，但“领域”到底指的是什么？

DDD通过分析业务，最终构建成一个个“领域”，设计出一个个富含业务行为的、饱满的“领域模型”。

在DDD里，“领域”指的就是一块业务范围。比如在一个电商系统中，可能会有“商品领域”、“订单领域”、“物流领域”、“仓储领域”等等。DDD通过战略部分指导我们根据业务划分出业务领域，并区别出哪些是核心领域，哪些是支撑领域和通用领域。这个我们会在本系列后面的文章中详细解释。

“领域模型”指的是业务的载体对象，比如“商品”、“订单”等等。这些对象具有一些有业务含义的方法，比如“商品.加入购物车”方法。我们把主要的业务逻辑内聚在领域对象里，这样一个操作要做的事情就变得非常清晰，并且易于维护。

简单来说，“领域”和“领域模型”能够更直观地表现业务，把业务真正落地到系统架构和代码设计上。

为什么需要DDD？

“即使我们的软件中没有bug，也不能表示我们设计的软件模型本身就是好的”。使用DDD，能够让我们的软件设计更加合理，但不止于此。

对于一个业务复杂的系统而言，使用DDD有如下好处：

  • 开发者和熟悉业务的人一起工作，加强团队间不同角色的合作；
  • 能够帮助业务人员和开发人员梳理清楚复杂的业务规则；
  • 开发出来的软件是能够准确表达业务规则的，设计就是代码，代码就是设计；
什么时候需要使用DDD？

使用DDD是有一些成本的，你的团队成员需要去了解DDD的一些基础知识，最好还需要有人做过DDD方面的实践，有一定的经验。

做任何事情都需要衡量成本和收益，技术方案的选型也不例外。DDD有一定的成本，但也能带给我们显而易见的收益。

一般来说，DDD适用于“业务复杂”的且“需要维护和扩展”的系统。

首先，我们来看看什么叫业务复杂。试想一下，如果你的系统只需要对几个简单的表进行CRUD，那你不需要使用DDD，甚至都不需要开发一个应用程序，直接使用一个数据库客户端可能就能解决问题。

从经验上来看，如果你的系统有30个以内的业务操作或用户故事，那也是没有太大必要去使用DDD的。而如果超过三四十个，软件就会有一定的复杂性，这个时候就可以考虑使用DDD了。

另一方面来说，即使现在这个软件并不复杂，但后续会进行开发和扩展，在可以预见的将来，它会变得复杂，那也可以考虑使用DDD。而一些初创公司，它们或许只需要一个简单的产品来快速测试市场反馈，后续并不会继续开发和维护，而是考虑重新购买或者从头开发的话，那也没有必要浪费成本去使用DDD。

所以再次总结我们什么时候需要使用DDD呢？业务复杂且需要长期维护的时候。

总结

其实纵观全文，可以发现DDD的核心就是一个词：业务。DDD的一切工具、实现都是以业务为中心，从业务展开的。所以如果要想实施好DDD，一定要认清业务的价值，关注业务，理解业务。