架构设计之路 - DDD领域驱动模型设计 - 补充中20220315
文章目录
- 前言
- 一、架构的演变历程
- 二、领域驱动初窥
-
- 1 传统软件开发中的痛点
- 2 什么是领域驱动设计
-
- 战略设计
- 战术设计
- 总结
- 3 领域模型
- 4 分层架构模型
-
- 三层架构
- 四层架构
- 六边形架构
- 三、架构设计进阶
-
- 1 DDD下的项目目录结构
- 2 XXXX
- 总结
前言
DDD 领域驱动模型设计
| 文章目录 |
|---|
| 《领域驱动设计》—— Thoughtworks洞见 |
| 《实现领域驱动设计》—— 沃恩·弗农 |
| DDD-领域驱动设计 - 知乎 (zhihu.com) |
一、架构的演变历程
学习DDD之前，先了解大致的架构模式，因为DDD本身也是一种另外一个层面上的设计模式，后面我们也需要从MVC与DDD进行一个最终的对比。
首先看一个传统网站架构的演变过程。
SOA 与 微服务
什么是SOA
Service-Oriented Architecture，面向服务架构，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。
**什么是微服务 **
维基上对其定义为：一种软件开发技术 - 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
总结
| SOA 面向服务架构 | 微服务 = 组件剥离+架构设计+领域建模 | |
|---|---|---|
| 描述 | 功能服务化 | 系统服务化 |
| 适用群体 | 快速开发，小型团队 | 功能间交互频繁、系统松耦合需求强烈 |
| 管理设计 | 中央管理/功能分化 | 系统分散管理 |
软件架构设计的实质是让系统能够更快地响应外界业务的变化，并且使得系统能够持续演进。从业务出发、面向业务变化是我们现代架构设计成功的关键。
二、领域驱动初窥
领域驱动设计 - Domain-Driven Design
1 传统软件开发中的痛点
常见的软件开发的方式我们可能会提到两个名词
- 瀑布式开发
- 敏捷开发
…我心里头一万个草泥马，这是啥玩意。
在最初时，项目组获得一个新项目后，与产品经理等经过产品标书及用户提供的需求进行整理形成一个初步的产品原型后交给开发人员进行编码，按照这种开发模式不断编码直到项目交付，但是在这种模式下的开发很难判断在这种基于现有的产品原型下是否符合用户需求，并且很难频繁的从用户那里得到反馈，在这种情况下必然与用户的心理预期差距较大，这种凶残而不择手段的暴力开发也十分对应瀑布式二字。
后来互联网人也吸取了教训，从上述的问题汲取经验，通过上述的基础上，不断地小步版本迭代、周期性交付、再每一次交付的基础上通过用户的反馈去精进代码业务，这样的好处在于我们通过这种快速敏捷的方式，不断去拥抱业务的变化，能够及时去根据业务情况进行修改，但是，在这样快速的小版本的迭代下，势必产生的问题是项目组工作成本的增加，在开发效率降低的同时，并且对开发人员的综合能力也要求更高。
问题的产生也对应了相应的解决方案，DDD应运而生，它是通过更小粒度的迭代设计、更加通用的语言，让模型之间、各领域之间彼此产生联系。
上面的东西比较玄乎，下面用一个非常经典的案例去描述，在每个互联网企业都会遇到的问题，就是程序员与产品之间沟通需求以及需求实现中，会不断发生摩擦，各说各话，互相都无法理解对方的意思，并且，在软件架构设计上，往往只有程序员团队自身进行设计，其他不懂技术的岗位十分难进来参与，因为他们无法理解一些专业的术语，仿佛在听天书一般。
所以，DDD存在的意义最关键的几点
- 让不懂技术的人参与架构设计 / 面对面协作建模
- review代码逆向建模
- 松耦合 + 易于理解的语言 + 语言统一标准化表达
但是，并非所有系统都适用于这一套DDD的模型设计，在一些比较基础需求简单的系统下，其实是不合适的，我们可以通过主观客观的方式对项目进行判断打分，查看是否应该引入DDD。
引入书籍《实现领域驱动设计》贴图。
2 什么是领域驱动设计
领域模型的概念源于2004年出版的经典著作《Domain-Driven Design –Tackling Complexity in the Heart of Software》（《领域驱动设计：软件核心复杂性应对之道》，简称DDD）。所谓领域，即软件所关注的主题区域。
在DDD方法提出后，分层架构的实现逻辑也经历了一波又一波的演进，直到后面马丁福勒（martin fowler）提炼出了下面这张图。
上面的图还是有些难以理解，先将相关的名词看完以后再来回味这张图，在DDD中从两个方面对边界进行定义
- 战略设计定义 - 从业务角度出发
- 战术设计定义 - 从技术角度实现
它们也是整个领域驱动设计的核心关键
战略设计
主要是对领域子域的内容进行说明
从上述的理论结合下面的实践图
1
战术设计
名词概念
1
聚合、实体、值对象、资源库、领域服务、领域事件、模块
1
1
总结
领域驱动设计的核心思想其实就是两个点
- 将问题不断的细粒度化
- 不同岗位间的项目相关成员的沟通协作 - 解决岗位间沟通的信息失真
3 领域模型
领域模型是对领域内的概念类或现实世界中对象的可视化表示，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
而我们将这种模型概念进行细化拆分，分为三种
- 角色模型 - 一个角色及该角色所承载的业务动作
- 实体模型 - 角色模型中对外交互的资源实体
- 用例模型 - 角色模型与实体模型的工作流程
通过一张图来更好的理解
然而对于领域模型的实现方式分为四种
-
失血模型
特点：只有getter / setter方法，不包含任何业务逻辑。
优点：简单。
缺点：它的简单直接导致其他层（如Service层）的复杂与笨重。
-
贫血模型
特点：包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到Service层。
优点：层次简单，便于维护。
缺点：主要代码被分配到Service层，过于笨重。
-
充血模型
特点：与贫血模型差别不大，区别在于业务及持久化逻辑的划分不再是Service层。
优点：Service层轻薄瘦弱化，更加面向对象。
缺点：依赖耦合度变高。
-
胀血模型
特点：取消Service层，在领域对象上封装事务逻辑。
优点：取消Service层，简化分层。
缺点：私有代码暴露面变大，稳定性变差。
上述说明了许多，其实领域模型设计的初衷也是为了帮助用户去建立业务的概念，确定领域及业务范围。
4 分层架构模型
分层架构模式被认为是所有架构的始祖。它支持N层架构系统，因此被广泛地应用于Web、企业级应用和桌面应用。在这种架构中，我们将一个应用程序或者系统分为不同的层次。
在分层架构中，我们将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层逻辑的依赖，因为它们不属于业务逻辑。将一个复杂的系统分为不同的层，每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。
在分层架构下大致上有两种情况
- 严格型：某层只能与直接位于的下层发生耦合。
- 松散型：允许上层与任意下层发生耦合。
三层架构
在传统的通用的三层架构下，基本能够通用于任何的开发环境、语言，它分为如下几层
上面相信大家都不陌生，在Java的MVC设计模式中其实与其蛮是相似。
- Controller - 控制层
- Service - 业务逻辑层
- Mapper - 持久化层
在传统的三层架构下，采用的是严格型的架构方式，每一层各司其职
-
表示层（UI - User Interface）
用户交互的部分。
-
应用层（BLL - Business Logic Layer）
对业务数据进行逻辑处理的部分。
-
持久化层（DAL - Data Access Layer）
对包括数据库在内的数据源进行操作的部分。
分层的核心目的是为了松解耦合及功能区分
四层架构
而在DDD领域驱动模型中，其所使用的传统分层架构，在三层架构的基础上中间新增领域层。
这是一个松散型的架构方式，并且是基于充血模型、面向对象的分层
- 用户接口层 - 负责所有对外的交互。
- 应用层 - 对标Service层，但该层仅做的工作是将业务传递给领域对象处理。
- 领域层 - 整个领域架构的核心，包含业务逻辑、数据实体、业务对象、事件等各类组件。
- 基础设施层 - 为上三层提供具体技术支持，将所有平台、框架、持久化相关的实现都放在该层。
六边形架构
将外层与内部应用的交互的数据转换逻辑交给适配器进行处理
在书上简化了上述的图片以后，就成了下面这番模样
这种架构下，对于内外部交互的边界更加清晰，松耦合，同时扩展性也是更强，能够及时拥抱外部的变化
三、架构设计进阶
1 DDD下的项目目录结构
| 文章目录 |
|---|
| 领域驱动设计（DDD）：项目目录（包、模块）结构 - Slashout - 博客园 (cnblogs.com) |
2 XXXX
1
总结
提示：这里对文章进行总结：
例如：以上就是今天要讲的内容。