DDD，领域驱动设计究竟是什么？

在互联网的萌芽时代，这会儿互联网还刚刚诞生，我们倡导“有即可”，能满足用户的基本需求即可；在互联网的野蛮生长时代，这会儿已经大量的玩家和网民涌入互联网，我们倡导“小步快跑，快速迭代”，能满足不同用户的不同需求；在互联网的稳定成熟时代，这会儿互联网红利已经薅的差不多了，网民就那么多，互联网之争也变为网民时间的争夺，这时候我们倡导“精细化运营”。

 

与“有即可”匹配的架构设计思想是单体架构，与“快速迭代”匹配的架构设计思想是SOA架构，而与精细化运营匹配的架构设计思想便是DDD领域驱动设计（DomainDriver Design）。那么为什么会有DDD出现？它解决什么问题呢？它是什么样？

 

01

 为什么会有DDD出现？

 

技术架构不匹配业务发展要求。在早期的时候，互联网刚刚出现，我们的要求都很低，功能也很简单，只要增、删、改、查即可。所以那会儿的业务，只要用PHP写个程序、连接Mysql数据库、搭在Linux系统之上就可以运行起来。于是乎就出现了一个模块里包含多个功能。

 

比如在电商平台中的订单服务，我们把下订单、支付、售后、评价等都放在里面，早期的时候功能很简单，只维护订单服务，只CRUD订单大表即可。但是随着业务的发展，当我们只想改支付功能或评价功能时，就不能轻易做改动了，因为改动支付的时候，有可能影响到售后。通过大量的测试虽然可以避免此类问题，但是投入的人力物力高。而DDD便可以很好的解决掉这个问题。

 

02

 DDD解决了什么问题？

 

在第一个问题中，我们可以看到答案很显然是系统架构设计不清晰，系统模块高耦合、低内聚。DDD提出以领域驱动设计的思想进行业务架构设计（根据业务需求设计业务模块）、系统架构设计（设计系统、子系统）、技术架构设计（采用技术及相关框架），将业务架构映射到系统架构上，业务需求变化时，系统架构也能随之变化。

 

在保证整个系统的相关人员（设计人员、开发人员、测试人员、维护人员）都在同一个认知上讨论事情的同时，也能快速高效响应业务需求。通过将业务架构映射到系统架构上，DDD所呈现的系统必然是高内聚、低耦合的，即在业务系统中，修改A模块并不会影响B模块正常使用。

 

03

 DDD是什么样？

 

在DDD中有一些关键名词，我们先来理解一下。领域，即某个有边界的业务的抽象，反应业务需求的本质；限界上下文，界定领域的边界；实体，即有唯一标识的对象，是一个持续存在、更新的生命，一般一个领域一个实体；值对象，即描述事物的对象，没有唯一标识；聚合，即一组相关的被视为整体的对象；聚合根，聚合的对象，外部对象访问聚合只能通过聚合根访问。进行DDD设计的步骤一般包含5步：

 

1.根据需求划分出领域、限界上下文；

2.分析每一个限界上下文中的实体、值对象；

3.聚合实体、值对象，划分出聚合范围、聚合根；

4.设计聚合根的仓储；

5.实际操作，不断反馈，迭代模型。不过只谈概念不实践，便是耍流氓。

 

那我们以设计一个秒杀系统为例，来看看DDD如何进行设计实践？

 

产品需求：在除夕夜当天举办一个秒杀活动，所有参加的商品都以超低价卖出，比如iPhone12、Macbook等，时间是20:00开始，先到先得，售完为止。拿到这样的一个需求时，首先我们根据使用用户可以拆分成两个领域，User活动域、Manager管理域。在User域，用户的整体使用路径包含参加活动、浏览商品、购买商品、售后评价，在这其中涉及到的领域包含活动子域、支付子域、库存子域、售后子域，为了保障刷单等行为不发生，我们还需要风控子域。通过DDD的明确领域划分，我们可以确定秒杀活动准入、支付、库存、风控的上下文，每个上下文对内高度内聚、对外低度耦合。

 

领域驱动设计（DomainDriverDesign）是一种新的软件设计方法论，它的思想是使用统一的语言将业务进行划分，保障开发人员、设计人员在交流时是针对同一个事务进行沟通，产品的业务架构能够完全映射到技术架构、系统架构当中。DDD最大的好处是统一交流语言，降低了沟通成本，但存在的难点是领域专家尚缺，它还是一个很新的概念，正在等待着更多最佳实践～