四色原型之我见

http://www.jdon.com/36343

学习四色原型有一段时间了，不过始终学得不明不白。与之相比，DDD倒是比较简单，实践起来也比较容易。今天又看了一些四色原型的文章，有点心得，到这和大家讨论一下吧！不过咱们还是和DDD进行参照着讨论。

1、领域对象 与 MI

首先是DDD。DDD的重点是“领域对象”，一切复杂过程的结果，落实到纸面上的，其实就是领域对象的关系图，说得更直白一些，其实就是 类图。这并不奇怪，因为DDD其实就是面向对象设计的精华。

那么四色原型呢？它的重点是"MI"，这并非本人乱扯，原书就是这么写的。那么 moment-interval 是啥呢？其实就是一个“动词”，我的理解是他一定是一个“动词”，例如 销售，记账，发送 等等。那么什么样的动词应该被归纳为 MI 呢？我的理解就是 DDD 的分析过程中，所指的“关键性动词”。业务虽然复杂，但是最后我们总是能归纳出关键性的动词，这些动词其实也就是我们业务模型的核心。

这里尤其想讨论的一点：
jdon 上包括其他很多人的观点是：MI 相当于 DDD 中的service。我想说这是严重的误人子弟。在 DDD 中，一个关键性的动作不可能存在于 service 中，而是应该存在于 领域对象中。所以结论就是： MI 不是 DDD 中的任何东西，而且 MI 的一些方法有可能会归结到领域对象中。甚至，MI直接就是一个领域模型。
（以上是我个人观点，正确与否大家讨论）

2、ppt 和 role

虽然四色原型的作者告诉我们：Role 是第二位重要的元素，但是我觉得 ppt 其实和 role 是同样重要的，尤其更多的时候，当你没有分析出 ppt 的时候，你也分析不出来 role。
例如，车是一个 ppt，坏掉的车则是车的一个role，良好的车也是车的一个role。在这种情况下，我们需要先分析出 ppt 这个东西。

误区：大家一提到 role，就必然联想到人。可实际上，在四色原型的分析方式里，很多物品也可以作为role。所以，很多人会把物品之类“没有生命的东西”分析成ppt，或者一个ppt的多个状态，这都是错的。

3、desc

desc这个元素是起到描述性作用的。大家都说它相当于 DDD 中的值对象，我觉得很正确----至少有助于理解这个抽象的东西。

4、四色原型，DDD 到底应该选择哪个？

四色原型其实正如其名字一样，是一种分析模式，而不是设计模式。
所以，分析阶段采用四色原型，而在设计阶段采用 DDD 应该是可以的。
不过---------在我的实际体会中，并没有遇到过如此复杂的系统，需要用四色原型去分析明白，然后用 DDD 去设计的，都是凭借分析关键的字词，简单的讨论，画一些交流的图，然后就可以归纳出领域对象，领域对象都有了，四色原型也就没有用了。

所以，在我看来，四色原型更像是一个学术理论的东西，虽然它可以帮助你分析一个业务如何设计更合理，但是它并不是必需的，而且遵循着迭代的模式，与其分析四色原型，不如画一些草纸，随时讨论来得方便。
即使是设计一些比较底层的架构，我也仍然认为不断的迭代，重构，分析领域模型会来得更快。

照这么说不是白学了？非也！分析阶段，适当的运行四色原型会有好处的，请注意：适当。

能够提出自己独特见解，很好。

我原来也曾提过或同意过MI与Service对应，这其实对简单情况如此，这是对行为的又一种片面认识，两者其实是不等价的。服务的概念更应该是一种接口，是设计领域中的一种面向客户调用的概念，在服务中我们不能放入所有的行为动作，这样就造成了失血模型；而MI是面向需求的一种活动概念，不只是行为，而是表达存在一段时间的行为，是一个过程，至于MI如何分解？肯定要落实到实体行为以及交互上。虽然最终有可能与服务Service表象很象，但不是服务，MI更类似NGOSS中Service概念，是分析领域的。

有时把四色原型就理解为需求分析或需求用例，至少和需求用例是平行的，我在表达需求时，常常在用例 类图 顺序图表达，而四色图相当于类图和顺序图的总结，本质是类图。

四色原型的原型意思一定要深刻掌握，它决定了四色原型在整个软件分析中的地位，它应该是软件的最最原始，与需求几乎无缝对接，这对于我们分析我们不熟悉的陌生领域有好处。

至于DDD，从名称也可以知道，它是偏重设计，目的虽然是统一分析模型和设计模型，但是，DDD的原始几个模型怎么来的？很多人是用名词罗列法，这虽然简单直觉，但是很显然不能上升为科学的方法，这时四色原型就能派上用场。