领域驱动设计概览

DDD(Domain Driven Design)

领域驱动设计
参考：https://www.jianshu.com/p/8dede848306a

相关概念

产品战略

伐谋战术：产品来源于市场，市场由两个C组成

• customer（客户需要什么？谁是客户?）
• competitor（竞争对手有什么?谁是竞争对手？）

架构

定义

架构是特定约束下决策的结果，并且这是一个循环递进的过程。参考：https://www.cnblogs.com/ivaneye/p/9752478.html

原则

架构要尽可能简单（在当前场景下尽可能简单便于扩展和维护），但是不能太简单（太简单在场景上会有遗漏）

目的

• 架构既要解决解决过去的问题，也要解决现在的问题，还要适度解决未来的问题，问题包括技术问题和业务问题
• 2纬角度：解决横向和纵向的问题，横向就是分层，纵向就是分区
• 3纬角度：在2纬的角度上考虑粒度问题（也就是微服务）
• 时间角度：架构不是一层不变的，是随着业务的发展不断演进的

分类

1. 产品功能架构：面向用户，描述产品能力；产品功能架构强调的是功能模块能力，受众是最终使用产品的用户
2. 业务概念架构：面向研发与业务人员，描述业务概念模型，模块，基本关系；业务架构是对业务的一种分析和理解，用来如何更好的构建产品，受众是产品的同学和技术同学
3. 应用逻辑架构：模块之间的联系和约束，粒度，职责，复用等等；描述模块间如何协同工作；应用逻辑架构强调的是研发时，各逻辑模块的职责，受众是研发同学和架构师
4. 应用部署架构：机房、硬件、网络；稳定性、性能、成本
5. 基础设施架构：中间件、存储、监控、报警

问题

任何一个软件系统存在都是有原因的，它都要解决特定的“问题”，否则就没有必要做这个系统。

定义

问题，可以理解成是现状和预期的落差，落差就是需求的真正来源，于是很自然的得出一个目标，知道自己的需求是什么？通过哪些事情来让未来达到预期？

如何确定问题是不是问题？

准确的定位问题是成功的开始，大部分糟糕的设计基本上是摸不清楚自己到底要解决什么问题，总是觉得这个问题我要解决，那个问题我也要解决，甚至不是问题的问题我也要解决，然后设计出了一个能解决所有“问题”的方案。比较常犯的错误是没有定位到问题本质：

1. 误把方法/手段当"问题"（解决洪水和财产安全，答案应该是疏导洪水，而不是堵）
2. 误把挑战当"问题"，（同洪水示例，认为洪水猛如虎，能把洪水堵住牛逼至极）
3. 思考问题时缺少时间维度，过了某个时间点，问题便不是问题，所以，有时候停下来、懒一点是好事儿

如何准确的定位问题呢？
可以为自己准备问题列表：

1. 我是在解决什么问题（这里要更多的站在客户角度去思考，要解决客户什么问题）？
2. 这个问题是已经发生的问题，还是未来将会发生的问题？
3. 问题背后的问题是什么，背后的问题的背后的问题又是什么
4. 我投入的大部分时间是讨论问题的定义？还是方案的设计？
5. 我当前解决的问题有多严重，投入产出比是否合适
6. 我定义的问题到底是客户的问题，还是方案中的技术挑战
7. 如果这是个老问题，那么在新的技术条件下，有没有新的解法
8. 对这个问题进行拆解的时候要使用升维思考吗，是否存在可能自己不知道的维度

一句话总结：我们不能只局限于问题本身，还需要看到问题背后的问题，然后才能更容易的找到更多的解决方案

问题空间和解决方案空间

定义

• 问题空间，是当前环境下业务所面临的一系列问题和问题背后的需求，属于产品规划阶段，通常是业务和产品领域专家主导问题、需求的收集描述和分析
• 解决方案空间，是针对问题空间的解决方案，这里思考的是如何实现软件系统已解决这些问题，属于工程实现阶段，由技术专家主导方案设计

软件开发过程

软件开发过程，本质上可以看作是问题空间到解决方案空间的一个映射转化：

1. 在问题空间里，是找出业务绵连的挑战及其对相关需求场景用例分析
2. 在解决方案空间里，是通过具体的技术工具手段来进行设计实现
   DDD不是关于技术的，而是关于业务讨论、聆听、理解、发现和业务价值的，这些都是为了将知识集中起来

领域

定义

• 领域：领域相对于软件系统来说，就是系统要解决的现实问题，一个领域对应一个问题空间，是一个特定范围边界内的业务需求的总和。领域来自于需求，但它却高于需求，相对于善变的需求而言，领域知识和领域模型本身是“静止”的，是“不变”的
• 核心域：是业务域的一部分，也是业务是否能够促成的主要因素，应该给予最高的优先级
• 支撑子域：对应着业务的某个重要组成部分
• 通用子域：如果某个域被用做整个系统，那这种部分就是通用子域