DDD领域驱动设计:业务分析神奇

1. DDD设计篇:运用事件风暴法进行业务领域建模、统一语言建模

DDD领域驱动设计:业务分析神奇

1.1 如何成为优秀架构师?

架构师 = 技术大牛?

架构师不仅需要懂技术,还要懂业务。

只有将业务落地到技术,开发出对用户有价值的产品,技术才是有价值的。

什么是业务架构师?

掌握了业务领域知识,掌握了业务痛点,然后用技术方案,解决业务痛点,才能为公司创造价值。

架构师

  • 要能够将业务转换为技术

  • 能合理运用技术支撑业务

客户买单,不是买技术,而是买你用技术解决我业务痛点的技术方案。

所以上面一步步分析后,业务痛点是关键

1.2.1 对业务及其痛点,有深刻的理解与思考

不仅要理解业务,还要挖掘出业务痛点,才才可以用对应的技术来解决问题

  • 分析业务流程

  • 理解业务规则

  • 挖掘业务痛点

1.2.2 能够将技术落地,产生业务价值

  • 规划高远却落不了地
  • 快速研发产生业务价值

关键难题:

  • 如何快速有效地学习业务领域知识
  • 如何深入地理解与挖掘业务痛点
  • 如何通过技术的手段落地业务

DDD领域驱动设计:业务分析神奇

系统没那么复杂时,需要领域驱动吗?

系统不复杂时,领域驱动有点大材小用,以前互联网时代没到来,没有发生数据和需求井喷,业务也不复杂,所以不会流行起来。

现在基本都需要,特别是互联网业务。

1.2 领域驱动设计在什么时候起作用?

1.2.1 在新项目开发中起作用?

DDD领域驱动设计:业务分析神奇

  1. 深刻理解业务,进行领域建模

  2. 然后把业务转换为领域模型,

  3. 再用领域模型指导数据库设计和程序设计

  4. 按照贫血模型或者充血模型转换为程序设计

这个时候,一开始需要花大量时间进行领域建模。

但是新项目有一些特点

1、复杂度没那么高

2、要快速交付

怎么办?一开始没办法,用领域驱动,是考虑长远,在日后,项目需求变更、维护。

1.2.2 在老项目维护中起作用?

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

面对老项目越来越复杂时,领域驱动会更好的发挥作用

DDD领域驱动设计:业务分析神奇

快速交付?

通过领域驱动设计,提高维护的质量,使得可以在业务不断迭代、市场激烈竞争、技术快速更新、系统越来越庞大时,依然能快速交付高质量的产品。

我们采用整洁架构,将业务代码和技术框架,通过一个中间层进行解耦。

今后,我们的业务代码随着业务不断迭代,技术框架也可以不断迭代调整,互不影响。

1.2.3 在技术架构演化中起作用?

1.3 领域驱动的解决之道

DDD领域驱动设计:业务分析神奇

首先,业务负责人(或产品经理),以故事的形式,将功能分发给多个敏捷团队,每个敏捷团队负责一个功能模块。

每个敏捷团队,在开发的过程中,结合领域驱动设计和微服务架构理念,设计功能。

我们按照业务去拆

微服务如何拆分?

接口怎么划定?

怎么将每次的需求只落到一个微服务里?

让每个微服务,都是软件变化的一个原因,

今后因为这个原因而发生的变更,都只发生在这个微服务。微服务的优势才真正发挥出来了。

每次需求变更时,基于领域驱动设计,进行业务建模,

最后把对业务建模的变更,落实到对微服务的变更

我们的系统才能高质量的低成本维护下去。

在我们结合领域驱动设计和微服务架构理念去做设计时,都是有一定的成本的,从而提高了系统设计的复杂度。

复杂度的增加,进一步降低了交付速度。又和我们的初衷产生矛盾。

我们的初衷,通过领域驱动设计和微服务,简化设计,降低维护成本,提高交付速度

而使用它们的成本,又会降低交付速度

这个矛盾怎么解决?

架构团队,架构一个支持微服务,支持领域驱动的架构,把我们在领域驱动中的一些复杂的设计,比如聚合、仓库、工厂下沉,落地到技术框架里,

一边基于业务领域模型,建立业务领域层,

一边将各个技术框架,通过适配器进行解耦。

这就是整洁架构。

DDD领域驱动设计:业务分析神奇

1.3.1 为什么需要领域驱动设计指导微服务的划分?

首先看下,传统的烟囱式的数据库设计

DDD领域驱动设计:业务分析神奇

这样的数据库设计,使用的时候,比如获取商品信息这个数据的时候,各个微服务都要去读取商品表,

一旦商品表发生变更,各个模块都要变更代码。

这样维护成本非常高。

怎么办?

那我们希望某一次变更,只需要改某个微服务的代码,缩小需求变更的影响范围

1.3.2小而专的微服务设计

小:拆分微服务

专:单一职责原则(容易被忽略)

怎么做?

要求每个表只能有一个微服务直接操作数据库,其他微服务想要操作是不行的,只能调用对应微服务的接口。

这样设计后,商品表变更,只会影响到商品维护这个微服务。

只要对外接口不变,其他微服务也不需要改代码,影响很小

DDD领域驱动设计:业务分析神奇

对数据表进行规划,哪个微服务操作哪些表。

提高内聚,从业务角度分析整理,划分清楚边界。

业界现在最有效的做这个事情的方法,就是领域驱动设计,

通过对业务的梳理,逐步建立起限界上下文。

然后基于限界上下文设计和开发系统

1.3.3 跨库关联查询解决方案

DDD领域驱动设计:业务分析神奇

方案:按照领域模型建模,建立好关联关系,底层架构自动帮我补填数据。

比如我下单,我只关心查订单数据,我建立领域模型时,建立了订单和其他模块的业务关系,配置好业务关系,底层架构自动帮我补填数据。

1.4 本课程要解决的问题

领域驱动设计的作用与意义

真正的目的不在于开发新项目,新项目没有那么复杂,而在于,日后的维护,系统越来越复杂时,体现出来。

一开始用领域驱动的意义,在于,日后的维护,系统复杂的时候,提高代码质量,降低交付时间。

怎样正确地进行业务领域建模

今天的内容

事件风暴

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

需求变更

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

为什么越来越复杂?

这是软件发展的必然规律

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

传统的设计方式,随着新需求的到来,不断地往payoff()方法里塞代码。

这样会导致代码质量不断下降,维护成本不断提高。

软件退化的根源,不是需求变更

当我们需求变更的时候,我们适时地调整代码。进行解耦和功能扩展,再去实现需求,就能够实现高质量代码

DDD领域驱动设计:业务分析神奇

那么我们怎样适时调整代码,解耦和扩展呢?

当发生10次、50次、100次变更后,可能就迷失方向了

我们需要一个方法,无论多少次变更,都能够产生高质量代码

当我们需求变更时,把变更还原到真实世界里,真实世界是什么样子,我们软件就怎么变更。

这样,无论发生多少次变更,我们也能找到方向。

DDD领域驱动设计:业务分析神奇

在领域模型里变更,思考设计

DDD领域驱动设计:业务分析神奇

面对变更,传统设计方式如下图,直接塞代码。

DDD领域驱动设计:业务分析神奇

而领域驱动的设计方式,我们先将新需求,还原到领域模型上,进行分析

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

我们要增加折扣,而且有多种不同方式的折扣。

我们需要思考,付款和折扣有什么关系?

折扣的功能,怎么添加到现有功能里?

传统思考方式:折扣是在付款的时候折扣,就写在付款的逻辑里

那么难道不写在付款里?为什么不该写在付款里?是基于什么原则去思考的吗?

有,单一职责原则

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

抽象出限界上下文,每个限界上下文就是一个微服务

每个微服务是软件变化的一个原因,有需求变更,只需要改某个微服务

怎样将模型转换为程序设计

明天分享

支持领域驱动设计的架构设计

第三天的分享内容

1.5 单一职责原则(SRP)

软件系统中的每个元素只完成自己职责内的事,将其他的事交给别人去做。

“职责”通常理解为一个事情,与该事情相关的事都是它的职责。

一个所谓职责,其实是软件变化的一个原因。

软件质量如何衡量?高还是低?

关键:维护成本

一个需求来了,我要改3个模块的代码

一个需求来了,我要改1个模块的代码

要求我们

平时,就要整理代码。

把同一个原因的代码放一起。

不同原因的代码分开放

DDD领域驱动设计:业务分析神奇

现在要增加折扣,问自己两个问题:

付款变了,要不要变折扣?不要

折扣发生变更,付款要不要变?要

折扣是付款的另一个变化原因,不应该把折扣放进付款里

1.6 领域驱动设计与传统软件开发有什么不同?

项目不变更,不需要添加新功能,不会越来越复杂,就不需要使用DDD

新项目里用领域驱动设计,是为了日后需求变更,维护起来更容易。

按照领域驱动设计,每次变更的时候,不是直接coding,而是把新需求,先放到领域模型里,在领域模型里设计,还原到真实世界。

领域驱动设计更适合老项目

是不是增加了工作量呢?

需要有一个支持领域驱动的底层架构

如何设计这样一个底层架构?

在第三天的课里

1.7 案例:远程智慧医疗系统

对前面的思想进行实战

DDD领域驱动设计:业务分析神奇

1.7.1 期初:传统的诊所管理系统

DDD领域驱动设计:业务分析神奇

护士接待患者,指引患者挂号,

然后由医生去看

医生建议患者去检查,做B超、验血

患者去交钱,验血

医生看报告,开药

患者交钱去药房拿药

1.7.2 统一语言与领域建模

DDD领域驱动设计:业务分析神奇

用客户的语言,理解业务

1.7.3 事件风暴

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

迭代会议之前,开一个事件风暴会议

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

已确诊和已开药是否是同一个事件?

DDD领域驱动设计:业务分析神奇

查找医生算不算一个事件?

只是个查询,不需要记录,预约了才要记录

领域事件分析全了么?还有已排班,已注册

DDD领域驱动设计:业务分析神奇

分析和事件相关联人和事

DDD领域驱动设计:业务分析神奇

预约是一个命令

触发者 是患者

相关的还有预约时间

出诊计划,哪个医生、哪个科室,什么时间出诊

梳理人和事的关系,

人和事是不是聚合

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

药品明细和处方是一个部分和整体的关系,有聚合关系,贴一个紫色便签

是不是聚合关系?

如果是聚合关系,部分的生命周期一定是在整体里

比如,处方产生了,才有药品明细,当处方删除,药品明细才会删除

1.7.4 领域建模

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

2 DDD实践篇:通过领域模型落地系统设计:数据库、聚合、工厂与仓库

DDD领域驱动设计:业务分析神奇

2.1 将领域模型转为数据库设计

表、表之间的关系

2.2 将领域模型转为程序设计

DDD领域驱动设计:业务分析神奇

实体、值对象(不要太纠结)

实体:每个同学,有一个编号学号,

值对象:同学、老师

DDD领域驱动设计:业务分析神奇

贫血模型的设计

DDD领域驱动设计:业务分析神奇

充血模型的设计

DDD领域驱动设计:业务分析神奇

充血模型的service,把订单作为一个整体,订单对象里有依赖的其他对象的,定义了他们的关系。订单service不需要处理订单和订单明细的依赖关系。

订单service只需要保存订单,也不需要关心保存到两个表

DDD领域驱动设计:业务分析神奇

订单和订单明细是聚合关系,订单仓库来做保存到具体的表的事情。

查询的时候,订单工厂,会补查用户、用户地址等信息

好处:

service不需要关注底层,只需要关注业务逻辑判断

是不是要为每个领域对象设计一个仓库和工厂?

框架

2.3 聚合

DDD领域驱动设计:业务分析神奇

对象和对象之间有整体和不分关系的时候,只操作整体

订单和订单明细是整体与部分的关系。聚合关系

查询和保存操作都是对订单,订单明细的查询和保存操作在订单里完成

订单就是聚合根

2.4 工厂(Factory)/仓库(Repository)

DDD领域驱动设计:业务分析神奇

2.5 领域驱动设计的分层架构

DDD领域驱动设计:业务分析神奇

dao变成了仓库,做了更具体的事情

2.6 互联网转型:远程接诊平台

DDD领域驱动设计:业务分析神奇

2.7 互联网转型带来的阵痛

DDD领域驱动设计:业务分析神奇

2.8 系统规划与架构设计

DDD领域驱动设计:业务分析神奇

互联网转型后的领域建模设计

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

CQRS命令查询指责分离

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

2.9 四色建模法

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

通过适配器,解耦业务代码和技术架构

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

DDD领域驱动设计:业务分析神奇

总结

  • 领域驱动设计适合大型复杂项目,不适合初始项目

  • 领域驱动设计适合频繁需求变更的项目

  • 通过领域建模,划分限界上下文,根据限界上下文拆分微服务

  • 有新需求或者需求变更,先将需求放在领域模型内讨论设计,再将领域模型转为数据库设计和程序设计

  • 领域驱动设计时,可以采取事件风暴会议形式,和领域专家一起,使用统一语言讨论,一起设计领域对象和关系

  • 事件风暴会议需要确定一些事情:分析有哪些领域事件、确定有哪些和领域事件相关的人和事、确定触发事件的命令、确定领域事件关联的人和事有没有聚合关系

  • 将领域模型分配到各个限界上下文中,构建上下文地图

  • 新需求的代码写在哪个模块里,采用单一职责原则作为指导

  • 单一职责中的职责是指引起软件变化的一个原因

  • 平时,就要整理代码,把同一个原因的代码放一起,不同原因的代码分开放

  • 软件退化的根源不是需求变更,而是在需求变更时,没有及时调整代码,没有正确的调整代码

  • 贫血模型设计的代码,领域对象只有状态,service层包含各种行为,service层很重

  • 充血模型设计的代码,更符合面向对象,领域对象不仅封装了状态,还有各种修改状态的行为,service层更轻,service层只处理业务逻辑的封装、事务、权限

上一篇:书籍推荐:《实现领域驱动设计》DDD书籍概览及百度云免费下载


下一篇:heoi2020树