四色原型的思考

学习四色原型有一段时间了,不过始终学得不明不白。与之相比,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 去设计的,都是凭借分析关键的字词,简单的讨论,画一些交流的图,然后就可以归纳出领域对象,领域对象都有了,四色原型也就没有用了。

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

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

欢迎大家讨论~
[该贴被yananay于2009-05-27 15:16修改过]
[该贴被admin于2009-06-03 13:42修改过]

>>虽然四色原型的作者告诉我们:Role 是第二位重要的元素,但是我觉得 ppt 其实和 role 是同样重要的,尤其更多的时候,当你没有分析出 ppt 的时候,你也分析不出来 role。
其实在谈论四色原型时,ppt更早入人们的视线,估计作者是认为:人(组织)、地方、物品比较具体好辨认,想要视而不见也都难,所以也就沒必要將它们的重要性往前提了。

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

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

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

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

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

[该贴被banq于2009-05-27 17:03修改过]

来点例子。
附件是3个四色原型的分析图。
这是一个楼盘相关的系统,其中一个简单的功能。三个图描述的都是一个功能,不过分析方式上有所不同。那个最合适?我想没有最合适的,根据实际情况来吧!
我想这也是很多初学者容易遇到的一个问题:总希望找到正确的答案--可实际上没有最正确,只有最合适。
[该贴被yananay于2009-05-27 16:33修改过]

f1

f2

f3

如果没有详细需求表达,这三个图看不出谁最合适,需要需求来作为标准。

嗯,是的,所以我说“我想没有最合适的,根据实际情况来吧”。
而很多初学者往往忘记“需求”。虽然大家也自己模拟需求,不过往往会迷失于其中。

那个图不。。。

看到这个帖子很高兴,因为这一段我一直在关注DDD和四色图,并试着将四色图应用到项目中来,可是总是觉得很牵强,不得要领,与是买了本《java modeling in color with uml》,对照着《DDD》看。
看到《java modeling in color with uml》中的例子“物料要求”(MaterialsRequest,也叫采购申请,这个业务我比较熟悉)时就迷惑了,如果要我画四色图,MaterialsRequest我会毫不犹豫的画成thing,对应DDD中的实体,但他却画成了MI,里面包含一些动作,他画的这个MI,应该是一个典型的实体(充血型的),整个图中并没有SERVICE的影子。
结论出来了,MI并不是指SERVICE,就是实体,最起码这个例子里是这样的。

我始终有些晕

lz还有在么?

关于MI原型有个疑问:
任何动作应该都不可能是一点完成的,比如说商店售出商品这个“售出”MI,书上说这是个moment,可是这个作业肯定包括了很多细小的动作,包括核对价格、打单记录等等,严格起来肯定是个interval的概念,要表示动作的时间的话一个interval应该足够了吧。

如果,MI中的M/moment其实是个“情境”或“情形”的意思,而不是个时间点的概念? 比如你上头的图中,“编辑”这个MI,肯定是因为“未销售”这个情形,不是么?所以我觉得这样理解好像比较流程点。。


另外,再请教一下,如果MI们涉及到很多的工序流转,对于某道工序,我必须知道它承接哪道又流向哪道,耗费了多少时间。这个时候,我觉得M就相当于SAP中的“移动类型”了,movement有流向的概念,结合thing就有流量的概念了,这样不是更能说明问题么?这样理解可以不?


初学小菜鸟,没有什么DDD概念,所以见笑了。

你好!请教不敢当,互相交流吧!

其实 MI:Moment-Interval,从名称来看,其实就是某个时间点,某段时间内相关的业务。
其实说白了,我的理解就是关键性的动词。

“比如说商店售出商品这个“售出”MI,书上说这是个moment,可是这个作业肯定包括了很多细小的动作,包括核对价格、打单记录等等,严格起来肯定是个interval的概念,要表示动作的时间的话一个interval应该足够了吧。”

这需要根据你的实际业务来具体分析了,如果你觉得一个“售出”MI足够分析明白业务了,那就用一个。
如果你觉得不够,非得需要 核对价格,打单记录,那就加上这些。

我觉得根本原因是你觉得那些东西是不是“关键”的。

而之所以 MI 是最重要的,就是因为它是“关键”的。