前言

以前，在产品设计阶段后端研发人员参与感较低，多半是PM主导这个过程，当PM产出产品设计文档与需求的时候后端研发人员一般脑子里浮现的是解决当前这个问题需要构建哪些表、表应该包含哪些字段、表与表之间的关系是什么样的，甚至会考虑到哪些数据放到redis里，哪些放到内存里，等这些技术细节。然后，依据这些技术细节来判断这个需求能不能实现、好不好实现、合不合理。那么实践DDD在这方面有什么变化吗？

DDD的产品设计

每一个产品都是为了解决问题域的问题而存在的，DDD要求研发人员将注意力聚焦在领域内发生的问题，然后设计一个模型来解决这些问题。So，Domain First！

领域通用语言

在和客户讨论需求的时候，研发人员一定要参与，并且与客户统一语言，确定领域内的专词术语，比如领域内大家都把User叫做客户，那么所有人在这个领域内就应该都以 客户 这个词来进行后续的沟通。下单 这个术语表示领域内的一个动作，那么以后再描述这个动作的时候就用下单。诸如此类。。

事件风暴

上面是我们落地DDD时候做的事件风暴
有了领域通用语言之后，我们就要用这些语言进行事件风暴。
所谓事件风暴就是所有人相关人员包括客户，在一起头脑风暴出领域内所发生的所有事件，事件一般以过去时描述，比如订单已下单、订单已删除。然后再在事件的前面加上产生这个事件的动作，如下单、删除订单。标记出这个动作需要遵循的一些规则，比如下单前检查库存，删除前确认订单是否完毕等，这些就是领域逻辑。
经过以上步骤之后标记处领域内的聚合，所谓聚合就是操作相关联的一些事件的主体，比如订单聚合。然后识别出聚合内的实体、值对象等。实体和值对象等战术建模的概念我会在后面的文章讲解。
最后把相关联的一些聚合放到一起，组成一个限界上下文，一般一个限界上下文对应一个服务，这个限界上下文（服务）会解决一个领域内的某个子域的问题。这个限界上下文就是一个大模型，里边由多个聚合小模型。