如何在DDD中建立领域模型 _DDD

作者 | TWInsights
在前文《??当我们谈论DDD时我们在谈论什么??》中我们讨论了DDD的战略设计和战术设计。在本文中我们将继续探讨领域模型。

文章插图
用领域模型表达领域概念在实际项目中，模型设计者往往过早陷入具体构造块类型的识别，比如实体、聚合、领域服务，而忽略了领域模型表达领域概念的目的。我们应该基于领域概念设计领域模型，然后再采用合适的模式降低领域模型的复杂度，进一步增加领域模型的表达能力。
领域模型的作用，一方面是关联代码实现，一方面是关联通用语言。我们对于模型和实现的关联轻车熟路，但是对于语言和模型关联往往有待提升。在沟通中刻意使用通用语言可以帮助我们验证模型的合理性。
我们以一个题目为例，方便后续讨论。
活动平台提供用户参与活动得到奖品的功能，吸引用户及潜在用户参与，以达到拉新、促活、引流的目的。
运营人员可以创建和修改活动，活动的配置内容包括活动名称、活动介绍、活动开放的开始时间和结束时间、参与资格、权益。
用户可以看到活动列表，在活动开放的时间段内进入活动页面看到活动介绍。用户在活动页面领取权益，经判断符合资格的用户就会获得一份奖品。权益可能是信用卡积分，也可能是优惠券。
参与资格可能是：一天内注册的用户、VIP用户、当月生日的用户等。客户希望系统可以方便扩展支持灵活的资格类型，以支持多样的活动形式。
对于一个活动，一个用户只能参加一次。
建立模型第一步是根据需求分析模型。
我们可以找到以下概念：活动、参与资格、权益。其中参与资格是扩展点。
对于需求「一个用户只能参加一次活动的」，需要记录用户是否参与过活动，所以需要「活动参与记录」的概念。

文章插图

【如何在DDD中建立领域模型】参与活动的结果可能有2种：符合参与资格则返回权益，不符合则返回「不符合」。所以我们用了Optional<权益>类型。
我们到这里只识别了各种名词，需要走查用例，寻找缺失的概念：

用例1，运营人员可以创建并修改活动
用例2，用户可以参与活动并获得权益

对于用例1，创建和修改活动，目前模型已经满足了需求。
对于用例2，这里有一个模型之外的规则：「一个用户只能参加一次活动」。这是所有活动都需要遵守的规则，我们将其称为「活动通用规则」。
虽然只是一个很简单的逻辑，但是提取「活动通用规则」这个概念非常有用。如果没有这个概念，那么每次去描述这个概念，只能用「一个用户只能参加一次活动的规则」去表示，非常繁琐；也让概念没有安身之地，容易被随便放到万能的Service中。
我们将其加入领域模型。

文章插图
PS：这里故意省略了参与资格的实现。
我们没有把「活动通用规则」放到活动概念里，一部分原因是这个判断逻辑不需要具体活动的信息。
使用通用语言验证模型有了领域模型，就有了通用语言。使用通用语言重新描述需求，并尽量在沟通中使用通用语言。
运营人员可以创建和修改活动，活动的配置内容包括活动名称、活动介绍、活动开放的开始时间和结束时间时间段、参与资格、权益。
用户可以看到活动列表，在活动开放的时间段内进入活动页面看到活动介绍。用户在活动页面领取权益，经判断符合资格参与资格的用户就会获得一份奖品权益。权益可能是信用卡积分，也可能是优惠券。
参与资格可能是：一天内注册的用户、VIP用户、当月生日的用户等。客户希望系统可以方便扩展支持灵活的资格类型，以支持多样的活动形式。
同时有「活动通用规则」：对于一个活动，一个用户只能参加一次。
这里去掉了「开始时间」、「资格」、「奖品」等模糊不清晰的描述。使用基于领域模型的语言，让需求描述清晰没有歧义。
到目前为止，主要的领域模型都已经分析出来。所有的模型都对应明确的领域概念，不多也不少。
识别构造块类型在分析了领域模型后，我们再来分析构造块类型。