DDD 是领域驱动设计，这个名字看起来很高大上，十分适合非开发背景的产品同学用来装13。但是 DDD 是个什么玩意呢？
其实很简单，每个公司都有不同的部门，每个部门都有自己要做的事，比如销售部门、技术部门、编辑部门。老板没必要让每个员工既能当销售，又能敲代码，还能舞文弄墨，因为这样的人太难招了。而如果把公司划分为若干部门，那么老板只需要招专业的人做专业的事就行，难度明显降低。
DDD 的思想也一样，开发同学在设计系统的时候，会分为若干层，每一层都有自己专门负责的事情，所谓「术业有专攻」。这样做的好处是，系统的扩展性比较高。
对于产品同学来说，没必要关心这些层都叫什么名字、每层里面都包含什么玩意儿、层和层之间如何互通……但产品同学需要了解的是 DDD 思想中的「领域模型」。
模型是什么？我们以一次就诊举例。
1.就诊过程中，我们会接触到许多人，如挂号员、门诊专家、收费员、药房药师，这些人都承担不同的角色。挂号员负责出售专家的号，门诊专家负责给你看病，收费员负责收费、药师负责取药。
2.我们非常清楚就诊的目标，就是「为了查自己到底什么病」。
3.整个就诊过程，由一系列满足规范要求的动作来完成就诊的目标，比如门诊专家需要给我们一个病历记录和药方，药师需要遵循专家输出的药方给我们取药。
「领域模型」其实就是类似的思维模式，以「就诊」作为出发点，把医生、药师等作为在就诊过程中可能遇见的角色，而「就诊」有明确的目标，整个过程中会存在一些列的动作才能达到这个目标。
领域模型中存在两类数据，一种是基础数据，性格内向；一种是业务数据，性格外向。业务数据可以让基础数据（实体）彼此关联起来，有点催化剂的感觉。所以建模的前提条件是：分清楚基础数据、业务数据。
催化剂太多不是什么好事，如果让基础数据之间建立了太多关联，那么这个模型一定是不稳定或难实现的。所以还是沿用前面的原则：「术业有专攻」，不要企图搞全才，踏实的去细化粒度吧，以前是神经血管，生活粗糙，现在是细胞基因，让生活精致一点。
细胞有细胞壁（植物），血管也有血管壁。细胞、血管就是聚合，而细胞壁、血管壁就是聚合边界。所谓聚合根，就像做支架手术，必须得先找到某动脉，然后才能顺着动脉找到需要放支架的地方，这根关键的入口动脉，就是聚合根。
对于领域而言，模型关系神马的，这一堆高大上的玩意，都可以抽象为「四色原型」，就像无论什么人，都可以用几个标签来概括他。那么，何谓四色？简而言之就是：什么人的角色、在什么地方的角色、用什么东西的角色、做了什么事。
人、地方、东西、事，就是所谓的四色。
继续前面就诊的例子：病人找专家看病，并拿到一个病历记录。
1.人：病人类型（哪个科室的病人）
2.地方：病人（在医院的角色是病人）
3.东西：专家（诊治方的角色是医生）
4.事：病历记录
如何利用四色原型让设计变得更灵活呢？
1.去掉病历记录和专家的关联，改为查询。即：通过专家来查询病历记录。因为一个专家可能会输出 n 份病历记录。但此时需要让专家关联一个病人就诊时的状态，因为我们想查询的是病人就诊时的病历记录，而不是现在的病历记录。
2.去掉病人和专家之间的关联，改为查询。
