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,一定要认清业务的价值,关注业务,理解业务。