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

推荐阅读

领域建模:如何用事件风暴构建领域模型?

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

推荐阅读更多精彩内容