DDD(domain driven design)-领域驱动设计

DDD(domain driven design)-领域驱动设计

domain driven design-领域驱动设计

• 领域驱动设计概述
• • 背景
  • 软件架构模式的演进
  • 概念
• 分层架构与六边形架构
• • 分层分包
  • • 复杂是我们软件生涯的一生之敌。
  • 分层架构 & 面向过程设计 - MVC
  • 六边形架构 & 面向对象设计 - DDD
  • 六边形架构图
• 代码结构MVC-DDD对比
• • MVC代码结构
  • DDD代码结构
• 探讨
• • 如何判断一个项目是否需要用DDD?

领域驱动设计概述

DDD(Domain Driven Design)
即领域驱动设计，核心是不断提炼通用语言并用于与领域专家等团队所有成员交流，并用代码来表达出一个与通用语言一致的领域模型。

背景

这些年随着设备以及技术的发展，软件架构发生了很多变化，从最初的单机(BS/CS)架构到后面的集中式架构，再到如今的微服务架构， 现在基本可以说是微服务架构盛行的时代，DDD早在2004年就由埃里克·埃文斯提出，但一直处于一个不愠不火的状态，直到Martin Fowler的《Microservices》引起大家注意，也就是微服务盛行之后(这儿需要说明的是，微服务最早的提出者不是Martin Fowler，而是Fred George)，DDD再次回到人们视野中间**

软件架构模式的演进

概念

下图很好的展示了领域，限界上下文，聚合，聚合根，实体以及值对象的关系。

分层架构与六边形架构 分层分包 复杂是我们软件生涯的一生之敌。

我们先回顾一下分层分包的概念：
分层是除“模块化”之外最古老的架构模式，冯诺依曼计算机模型是模块化的架构，但同时计算机世界也是层层叠加的。分层分包的本质就是隔离，人处理难题的能力是有限的，无法同时处理很多复杂的事情，所以不把所有东西都放在同一层次，譬如行政体系也是分层的。隔离使得各个层次职责更清晰，更容易管理。

分层的原则是只能上层调用下层，而不能反过来，反之容易导致循环依赖。分包的原则是，同一个包中的对象天然是亲和的，同时对包外的对象是不亲和(隔离)的。

分层架构 & 面向过程设计 - MVC

缺点：
一个服务方法几乎包含了所有的逻辑，负责校验、获取外部信息、组装、转换SpuDTO为SpuDO、并调用SpuMapper保存到数据库，SpuDO为失血模型。
耦合性强，在各种service（如MaterialService，CategoryService）内部注入，重构/扩展性差。
优点：
在逻辑很简单场景下，crud迭代最快。 MVC保证了代码最差也差不到哪去（基本总是最差）

六边形架构 & 面向对象设计 - DDD

优缺点：
DDD如果做的差，会比MVC还要差，如果做的好，的确可以应对业务的变化（了解业务，预测业务的变化）。
业务逻辑清晰度高。
防腐层隔离变化。
充血模型扩展性高（当MVC耦合成一团山的时候，还敢随便改SpuDO的信息吗？除非读懂每一个Service的调用过程）
各领域自治，可以自我发展。

六边形架构图

六边形架构又称“端口和适配器模式”，是计算机博士Alistair Cockburn提出的一种具有对称性特征的架构风格。在这种架构中，系统通过适配器的方式与外部交互，将应用服务于领域服务封装在系统内部。

代码结构MVC-DDD对比 MVC代码结构

• Controller: 对外暴露的服务
• Service：服务层
• impl: 逻辑层
• mapper：数据库交互

DDD代码结构

• gate: 对外暴露的服务
  • rest：对外暴露的rest服务
• application：应用服务层
• domain：领域层
  • category: 分类
  • unit: 单位
  • sku: 规格
  • spu: 商品库
• infra：基础设施层
  • repo：仓储实现
  • mapper: 数据库交互

探讨 如何判断一个项目是否需要用DDD?

业务：快速变化

需求变更快，需求迭代快，业务扩展快的项目。

开发人员：3-5年经验

需要熟练应用过很多设计模式，有了这些经验才能理解为什么这么设
计，才能不偷懒的去做这件事，否则很容易对领域造成污染。

时间：更充分

需要有充分的时间去划分业务，设计领域，需要更多的类，编写更多
代码量。