“如何得到完美的领域模型设计”属于一个谜一般的问题，这类问题往往复杂而独特，一些既有的方法，对某个项目适用，并不一定对另外一个项目也适用，用一句 ZB 的话来说，就是：
这是一项艺术。
从复杂问题转到可以解决的问题需要不停的启发和探索，即把艺术工程化或者流程化，去掉其中的文艺范。推理，发散，类比等等都是这个阶段很重要的技能。
今天讨论的重点是领域模型设计，鉴于设计本身是一个不停迭代的过程，于是在这里我们先引入一个成熟的流程工具：PDCA
PDCA 是英语单词 Plan(计划)、Do(执行)、Check(检查)和 Adjust(调整)的第一个字母，PDCA循环就是按照这样的顺序进行质量管理，并且循环不止地进行下去的科学程序。
我来结合领域建模在这四个阶段分别要处理那些问题
Plan
确认目标，计划，方法等
一般来说领域建模的目标是 ER 图，至于方法，可以用四色建模(可以参看徐昊的那篇文章)，或者大部分程序员都很喜欢的
**凭感觉建模**
Do
执行上一步所指定的计划和程序, 收集必要的信息来为下一步进行修正和改善提供依据.
Check
检查是研究上一步收集到的信息(ER 图)，利用一定规则和预期目标进行比较，并提出修改方案，包括执行后的改善和计划的完善使得计划的可执行性提高
Adjust
对总结检查的结果进行处理，对成功的经验加以肯定，并予以标准化；对于失败的教训也要总结，引起重视。对于没有解决(好)的问题，应提交给下一个PDCA循环中去解决。
如果仅为了解决有无的问题，只要一个迭代，甚至半个迭代（P和D）就可以了，但是如果要解决好与不好的问题，Check 这一步就显得很重要了，因为这一步即可以 评价当前工作成果，也可以指导后续工作流程
众所周知，正确性，健壮性和易用性是IT系统最重要的几个指标，同样的，我们考虑领域建模的时候，也可以分别拿着这些指标来做 Check。
一个设计的正确性取决于该设计满足问题实际需求的程度。站在“客户永远是正确的”这一基础上，于是在拿到需求后，我们先提出三个问题。
- 被设计的需求中有几种角色?
- 每个角色在这个场景需要被解决的需求是什么(收获)?
- 需要角色在这个场景中做些什么(付出)?
当然，从获得设计产物的角度出发，我们还要提出两个问题
- 每个角色在这个需求场景中需要哪些数据?
- 每个角色在这个需求场景中会产生什么数据?
易用性是指用户使用软件时是否感觉方便。同样的，我们要问这样一些问题
- 每个角色在这场景中的收获，能否可以通过其他方式(付出)获得?
- 对于这个角色来说，那个方式是最方便的?
- 由于角色之间会出现交互，因此一种角色方便了，是否会影响到其他用户的体验?
- 如何权衡各种用户的体验，即保留谁的体验，牺牲谁的体验?
- 如果谁都不能易用，是否是需求除了问题?
软件设计的扩展性是指，通过很少的改动甚至只是模块的添置，就能实现整个系统能力的线性增长的能力。这个阶段我们就要问另外一些问题
- 新需求的模型设计，是否是对现有架构的造成了冲击?
- 新需求的模型设计，能否为将来的需求提供系统能力的线性增长？
以上从不同维度提出了一些关于好设计的 CheckPoint ,有些CheckPoint之间是有冲突的，比如不同角色的客户体验。一般要有所取舍，比如要牺牲 admin 的用户体验而保证 user 的用户体验, 在具体使用时还要灵活处理。
下面我们以一个遗留系统中增加一个讨论功能为入口，举例来看。
这个讨论系统的第一版需求如下
- 用户角色分为普通用户和管理员
- 普通用户可以发起一个主题(subject)
- 普通用户可以查看主题，并在此主题下进行回帖(post)
- 学员可以修改自己的回帖
- 管理员可以对 subject, post, 进行删除操作
先来一个 User Journey
有了这两张图，我们接下来就要考虑建模了，我们两个问题，
- 每个角色在这个过程中会用到那些数据。
- 每个角色在这个过程中会产生哪些数据。
结合这两张图，我们可以很容易的找到答案，我们会用到3个表(实体)，分别是 user(admin), subject, post。
我们把其中 admin 也作为一个 user， 仅用 role 字段来区分
据此，我们可以得到第一版的 ER 图(可以先不用着急考虑字段)
虽然第一版的建模已经完成，但我们还要看看，有没有复用的可能，通过和 PO 进行沟通，我们得知，系统将来有可能要加一个针对习题问答系统，这个问答系统主要是针对于现有系统中的某个练习题 (item) 进行讨论，这个问答系统的要求如下
- 习题问答的主题 (item subject) 由系统按一定规则自动创建
- 用户先进入题目，然后才能进入习题讨论，
- 用户可以向这个习题讨论提交答案(answer)
- 用户也可以浏览这个题目下的所有答案
- 用户可以就某个问题进行评论(comment)
同样的，我们需要先变身为用户，画出 user journey 来
仔细分析，我们就会发现这个需求跟上一个需求是有类似的地方，我们可以通过抽象得到一个新的ER图，