DDD | 入门 - [概念体系]-编程知识

INDEX

- - 接触 DDD 前的准备
  - - 不要用和 MVC 对照的思想去接触 DDD
  - 领域 & 子域 & 界限上下文
  - - 思路
    - 领域
    - 子域
    - 界限上下文
  - 领域的初步划分

接触 DDD 前的准备

不要用和 MVC 对照的思想去接触 DDD

不要用和 MVC 对照的思想去接触 DDD，这样你会很痛苦。
在之前蛋式编程这个帖子中阐述过，当我们使用 MVC 时，其实是在进行一个填表游戏，因为可以很自然的拆解出两个维度，业务以及我现在在针对那个层进行开发，如下图：
在这里插入图片描述所以，其实理论上一个 MVC 架构的项目在需求明确的一瞬间，上面的表格就已经确定了，同时，类的数量和他们各自是干什么的也已经确定了。

而在使用 DDD 时，我们可以理解为是收拾杂乱房间的过程
在这里插入图片描述
当我们开始使用 DDD 可开展工作的时候，我们面前尚未建模的部分就像这间屋子。如何收拾这样的屋子，我们需要归置散落的衣物，收拾未归为的小工具，收拾桌面，清理地面……

经过评估，上述工作我们都需要完成，任何一个缺失都不能算是我们已经完成了房间的清理，因此，我们认定刚刚提到的都是不同的领域。他们具有等同的地位，并且都需要分别关注。

然后，我们把目光聚焦到衣物上，那么衣物充斥了我们的视线，这是我们目前需要处理的领域。刚刚说的其他的问题？去他大爷的吧，现在我们只管衣物。然后，我们开始领域内建模，如何收集、折叠、识别、收纳这是后话，跳过。

总结刚刚经历过的过程，如下图所示

我们从杂乱的业务信息中挑出一个
以这个信息为核心聚拢周围的混沌，形成一个独立的小混沌团以完整的描述刚刚那个信息相关的所有
现在这个小团的，就是以前混沌的业务里的一个方面
重复上面的过程，使一开始的那一大团混沌不在有任何残留，完全只剩下若干个小的

领域 & 子域 & 界限上下文

思路

我们怎么理解 DDD 中的领域。
先将它理解成业务系统本身，或业务系统一部分业务本身。这里需要注意一个误区，领域是你公司进行整体的业务或其一部分，而不是你正在开发（或者既存）的项目中业务的一部分。

这会导致很多开发人员认为自己目前项目中的一个模块就对应 DDD 中的一个领域。
而事实上并不是，可能你的项目整体上只是你所在部门的一个领域，甚至你所在公司整体业务中划分出来的众多领域中的一个。而你之前认为的模块，其实应该对应 DDD 中的一个界限上下文。

DDD 旨在使用领域模型进行设计，但绝不是希望将业务系统设计为一个整体、所谓内聚、完全功能的模型。而是在模型里架构一个结构清晰的体系，这个体系以领域为核心视角。

一个还处于混沌的领域中可能包括很多事物

我们通常认为，从业务视角出发，如果一个事物与其他的事物都格格不入，那就应该排除在领域之外
我们通常会确认这些事物中的一个作为当前这个领域的核心。如果存在多个我们确认这是业务核心的事物，那通常意味着需要对目前正在讨论的领域进行拆解，至少形成多个界限上下文甚至多个领域
然后我们会发现，有一些事物并不是当前这个领域的核心关注点，但是它依然是领域的一部分。这些事物中的一些和当前领域的核心业务本身有关联，而另一些可以和很多领域产生关联

按刚刚粗略的划分，我还已经规定了领域和子域，其中子域又被细分为了核心子域、支撑子域、通用子域

现在，我们只是贴着领域进行了划分：把领域切割为了子域和子域之间的协作关系。但各个子域中，依然是混沌的，我们需要开发它。而开发一个混沌的东西的前提是我们需要先能准确的描述它，在 DDD 的核心思路里，开发是一个以领域业务专家为核心，专家、需求提出人、研发人员一起协作的集体行为，因此这要求我们可以准确并且统一的描述目前混沌的部分。准确并且统一的描述就是通用语言，通用语言在领域中的作用范围就是界限上下文。

领域

一块业务 A 本身

子域

核心子域：领域中直接决定领域是否成功的那部分，领域业务里的核心焦点，可以认为核心子域就是当前领域想做的事本身
支撑子域：领域中不可或缺，是业务的重要方面，但是又不属于核心的部分。这些子域对应的概念，很有可能是另一个领域中的核心域，但在当前的领域里，它虽然重要但也不是我们的核心关注点，所以只是一个支撑子域
通用子域：在领域中有体现，但他被广泛的应用于整个业务，那它就可以被定义为一个通用子域。一个简单的区分支撑子域和通用子域的方法：只从可行性上进行分析，你的项目敢通过购买的方式得到这个子域吗？如果可行，那就是通用子域