DDD实践思考

DDD(domain driven design)

领域驱动设计强调技术专家和业务专家，通过统一的语言来完成领域的建模，帮助技术侧和业务侧形 成一套统一的语言.
DDD就是以领域为入口，来解决产品设计，研发的思想。

什么场景适合使用DDD

并不是所有场景都适合使用DDD,DDD纵然有千般好,复杂业务建模以及业务场景不确定的任务.

DDD落地的步骤实践

业务建模

通过需求梳理,形成用户故事地图 .

1、梳理需求

• 梳理用户角色/用户群体
• 梳理任务(任务是用户操作的最小粒度)
  举个例子: 经常在用户故事地图中看到角色Who需要做What,我们可以将任务类比为一个API或者多个API.
• 活动
• 命令

他们之间的关系是:
角色:活动 = 1:n。活动:任务= 1:n,任务:命令=1:n

• 识别领域对象
• 将业务建模的命令移动到新建的领域,把命令移出领域对象,命令在领域对象间转移.

2、形成用户地图

做完上面的步骤之后,就形成用户故事地图, 用户故事地图自由好不好用,没有正确的用户故事地图

3、识别领域对象

我们以用户故事地图为基础,识别或抽象与任务、命令最相关隐含的业务概念, 一般来说是命令、角色、任务、规则中的名词,领域对象,并围绕领域对象相关的命令,划分职责边界

4、划分模块和微服务

将所有的领域对象提取出来,画出领域对象之间的依赖关系,领域对象之间的一对一、一对多、多对多的关系.

5、将领域对象归类的模块(活动)

将领域对象归类到模块、活动

技术建模

• 识别实体
• 划分为服务
• 分配职责
• 设计数据库

识别实体

识别核心的业务逻辑技术载体,领域对象映射

划分微服务

发挥云弹性,敏捷的优势, “高频-重要”四象限等

分配职责

内聚业务逻辑
贫血模型逐渐充血

设计数据库

资源集约地实现可用性等非功能需求
涉及ORM表、数据库拆分