DDD实战篇 - 权限域战略建模

领域这个词语承载了太多的含义，既可以表示整个业务系统，也可以表示其中的某个核心域或者支持子域。

账户域可以分为：权限子域和用户信息域（子域下面还可以再接在划分出子域，没有最小的子域，只有最合适的子域）。

权限子域又可以分为：认证上下文和授权上下文。对于限定上下文，我们把重点放在界限上。

比如，“顾客”这个术语可能有多种含义。在浏览产品目录的时候，“顾客”表示一种意思；而在下单的时候，“顾客”又表示另一种意思。原因在于：当浏览产品目录时，“顾客”被放在了先前购买情况、忠诚度、可买产品、折扣和物流方式这样的上下文中。而在下单时，“顾客”的上下文包括名字、产品寄送地址、订单总价和一些付款术语。

1. 事件风暴

在领域建模过程中，我们需要关注这类业务语言和行为。比如某个业务动作或者行为（事件）是否会触发下一个业务动作？这个动作（事件）的输入和输出是什么？是谁（实体）发出的什么行为（命令），触发了这个动作（事件）...我们可以从这些暗藏的词汇中，分析出领域模型的事件、命令和实体等领域对象。

权限域有三个典型的业务场景：

1. 资源和角色设置；
2. 用户分配角色，创建账户和密码；
3. 用户登录系统和权限系统，生成用户登录和操作日志；

我们可以按照业务流程，进行场景分析：

1. 搜寻用户业务流程中的关键领域事件，比如资源创建，角色创建，用户创建等事件。
2. 再找出什么行为会引起这些领域事件，这些行为可能是一个或若干命令组合在一起的。
3. 领域事件会触发下一步的操作，比如发布到邮件系统通知用户创建；

场景分析时会产生很多命令和领域事件：

事件风暴.png

2. 领域建模

领域建模时，我们会根据场景分析过程中产生的领域对象，比如命令、事件等之间的关系，找出产生命令的实体，分析实体之间的依赖关系组成聚合，为聚合划定限定上下文，建立领域模型与领域之间的依赖。领域模型利用限定上下文向上可以指导微服务设计，通过向下可以指导聚合根、实体和值对象的设计。

2.1 提取实体

从命令和事件中提取产生这些行为的实体。用绿色贴纸表示实体。通过分析权限模块的命令和事件等行为数据，提取了产生这些行为的用户、账户、认证Token、资源、菜单、角色和用户日志七个实体。

划分实体.png

2.2 划分聚合

将实体划分成聚合，这上面的7个实体都可以独自作为一个聚合。

大话DDD — 服务、实体、值对象、聚合根

2.3 划分限定上下文

划定限界上下文，根据上下文语义将聚合归类。根据用户域的上下文语境，

• 用户基本信息和用户日志信息这两个聚合共同构成用户信息域，分别管理用户基本信息、用户登录和操作日志。
• 认证Token和账户这两个聚合共同构成认证域，分别实现不同方式的登录和认证。
• 资源、角色、菜单共同构成了权限域。

权限域上下文.png

2.4 转化为领域模型图

将上面的图转化为技术人员可以理解的领域模型图。

领域模型图.png

推荐阅读

领域建模：如何用事件风暴构建领域模型？

领域驱动设计之实战权限系统微服务