|
学习四色原型有一段时间了，不过始终学得不明不白。与之相比，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的原始几个模型怎么来的？很多人是用名词罗列法，这虽然简单直觉，但是很显然不能上升为科学的方法，这时四色原型就能派上用场。 看到这个帖子很高兴，因为这一段我一直在关注DDD和四色图，并试着将四色图应用到项目中来，可是总是觉得很牵强，不得要领，与是买了本《java modeling in color with uml》，对照着《DDD》看。
看到《java modeling in color with uml》中的例子“物料要求”（MaterialsRequest,也叫采购申请，这个业务我比较熟悉）时就迷惑了，如果要我画四色图，MaterialsRequest我会毫不犹豫的画成thing,对应DDD中的实体，但他却画成了MI,里面包含一些动作，他画的这个MI，应该是一个典型的实体（充血型的），整个图中并没有SERVICE的影子。 结论出来了，MI并不是指SERVICE,就是实体，最起码这个例子里是这样的。 关于MI原型有个疑问： 任何动作应该都不可能是一点完成的，比如说商店售出商品这个“售出”MI，书上说这是个moment，可是这个作业肯定包括了很多细小的动作，包括核对价格、打单记录等等，严格起来肯定是个interval的概念，要表示动作的时间的话一个interval应该足够了吧。 如果，MI中的M/moment其实是个“情境”或“情形”的意思，而不是个时间点的概念？ 比如你上头的图中，“编辑”这个MI，肯定是因为“未销售”这个情形，不是么？所以我觉得这样理解好像比较流程点。。 另外，再请教一下，如果MI们涉及到很多的工序流转，对于某道工序，我必须知道它承接哪道又流向哪道，耗费了多少时间。这个时候，我觉得M就相当于SAP中的“移动类型”了，movement有流向的概念，结合thing就有流量的概念了，这样不是更能说明问题么？这样理解可以不？ 其实 MI:Moment-Interval，从名称来看，其实就是某个时间点，某段时间内相关的业务。
其实说白了，我的理解就是关键性的动词。 “比如说商店售出商品这个“售出”MI，书上说这是个moment，可是这个作业肯定包括了很多细小的动作，包括核对价格、打单记录等等，严格起来肯定是个interval的概念，要表示动作的时间的话一个interval应该足够了吧。” 这需要根据你的实际业务来具体分析了，如果你觉得一个“售出”MI足够分析明白业务了，那就用一个。 如果你觉得不够，非得需要 核对价格，打单记录，那就加上这些。 我觉得根本原因是你觉得那些东西是不是“关键”的。 而之所以 MI 是最重要的，就是因为它是“关键”的。 |
|
|
