领域驱动设计(DDD)——应用架构落地方案

1. 什么是DDD

与传统设计相比,总结了以下两个维度的不同点
设计思维
在传统设计思维里,会先设计表结构,然后根据表结构进行业务代码的开发,聚焦点在数据库上。而DDD是要先构建领域模型,也就是把需求拆分成独立的模块,这些模块有自己独立的功能,并与其他模块相互协作。DDD的聚焦点在领域模型上,一切都以模型为基础。
编码风格
虽然现在用的开发语言都是面向对象语言(比如Java),但是实际开发中还是采用的面向过程编程,因为现在的编程风格都是把数据模型和行为模型分开的,随着业务的不断迭代,每个类逐渐变成“上帝类”,数据模型类变成了一堆不相关的字段的组合,Service类里的逻辑也变得非常臃肿。
DDD是真正的面向对象编程,DDD的核心类结构如下:
Value Object类:或者称为Domain Primitive,是领域里的最小单元,并且是无状态的。如手机号Phone,这里的Phone不是一个字符串,而是包含了字符串phone和实现对手机号规则校验的一个类;
Entity类:有状态的实体类,每个实体类应有自己完整的属性和行为,提供完整独立的功能。实体类里的属性不同于传统的数据模型是一 堆无关联的字段的组合,实体类里的属性一定是相互关联的,就像汽车发动机的所有零部件共同组成了这一能独立运行的实体;
Domain Service:提供跨域间的操作,将多个不同的域对象装配起来,使其相互协作,形成一个完成的功能。

2. DDD架构

领域驱动设计(DDD)——应用架构落地方案_第1张图片

从架构图中可以看出,最底层不再是数据层,而是领域层。对于业务系统而言,数据库和其他第三方资源及客户端都是输入或输出,数据库只是业务产生数据后的一个存储介质,不应该介入到业务系统中。领域层是纯内存操作,不依赖任何外部系统。与外部系统的对接都是在应用层(Application Layer)处理,应用层依赖领域层。

3. 服务边界划分规则

  • 从需求文档中提取业务要素(核心名词)
    要与产品经理充分沟通,了解需求的背景、意义及未来规划(前提是要有一个文档编写能力强,规划能力强的产品经理,做开发的应该都懂~)。这些核心要素是定义服务的雏形。
  • 每个服务必须是一个独立运行的单元
    或者说必须要实现功能闭环。比如电商系统的订单服务、商品服务,订单服务可以实现下单功能的闭环,商品服务可以实现对商品的全生命周期管理。
  • 单一原则
    服务必须是高内聚、单一职责,不能出现“你中有我,我中有你”的情况,服务之间相互交织会使系统变的异常复杂。

4. DDD设计流程

4.1 绘制领域模型图
领域模型图要描绘出业务要素之间的关系,是怎样进行协作的。这里以汽车系统为例,汽车系统是非常成熟的设计,其结构设计思想值得我们软件开发者借鉴。汽车的核心要素主要有三个:发动机、变速箱、底盘。
领域驱动设计(DDD)——应用架构落地方案_第2张图片
4.2 定义系统操作
系统操作是指前端页面对整个系统发出的各种请求,不是具体到某个服务,系统操作定义完之后再把每个操作分配到各个服务去处理。

操作 参数 返回 操作条件 操作结果
启动 发动机Id、档位 启动成功或失败 档位在额定范围内 汽车启动成功并行驶

4.3 绘制领域对象模型图
这里要说一个新的概念,聚合。聚合类似于汽车系统里的机构,机构是由一组零部件组成的可以独立运行的单元,如发动机。同样的,聚合是由一组领域对象组成的完成某个独立功能的集合体。聚合有且仅有一个根对象,外部对象只能依赖这个根对象,外部对象也只能通过这个根对象操作聚合内的对象。
领域驱动设计(DDD)——应用架构落地方案_第3张图片
4.4 绘制服务间关系图
服务关系图要能够表达出服务之间的协作关系。下图中采用的是六边形架构图绘制
领域驱动设计(DDD)——应用架构落地方案_第4张图片

你可能感兴趣的:(云原生,java,系统架构)