DomainModel之鸟瞰

第一次接触GoogleEarth，带给我相当的震撼。你可以随意转动地球，通过缩放，看到不同层次的景象，这着实让我吃惊，竟然可以这样！手握鼠标，来回查看，有种作“上帝”的感觉，如果是实时的那就不得了了！相信很多人都有在上面寻找自己家的经历。就拿我来说，首先转到背面中国的位置，滑动滚轮，逐渐深圳的全貌显露出来，西面是蛇口黄色的填海区，上面是深圳的绿肺塘朗山。继续向下，黑灰色的广深高速开始清晰可见，在我辨别清楚小区所在位置后，范围进一步缩小，旁边高级中学里红色跑道包围的足球场，看起来很规整，小区游泳池，也从一个小蓝点逐渐露出了它的钢琴造型。最后停放在小区里的轿车也显露无遗。

  GoogleEarth提供了一个可伸缩的鸟瞰视角，生动的展示了我们所处地方的本来面貌。这不同于，我们每日看到的景象，也不同于我们曾经看到的地图和地球仪。在DomainModel中，虽然没有GoogleEarth for DomainModel的特殊版本。但我们可以采用类似的方法来查看我们的Model。

  在明确了DomainModel控制风格和演化规律后，我们还需要确定DomainModel中各部分的依赖和职责，才能得到整体观感。

“从演化规律来看，要理解生命周期短者的观点，必先理解生命周期长者的观点”:)

我们先考察OO大师PeterCoad等的著作--Java Modeling In Color With Uml。
PeterCoad关于企业信息系统观点的努力，首先在Object Models:Strategies,Patterns, and Application中得到表达，随后，在Java Modeling In Color With Uml中，通过“Domain-Neutral Component”更系统的完善了他的构想。

“色彩迷”PeterCoad“四色论”观点，简单可表达为“特定领域构件，用四种领域中立，按照重要程度分配颜色的构件原型，建立模型。”

四种构件原型为：
“moment-interval”--代表领域中可长可短的业务交互。因其地位最重要，故用扎眼的粉红色表示。
“party, place, or thing” --表示“moment-interval”中，涉及的实体。其地位在“description”之上，而在“role”之下，用舒服的绿色。
“role”-- 是指“moment-interval”中，"party, place, or thing"的参与方式。地位仅次于“moment-interval”，第二刺眼，黄色。
“description”-- 用来描述上述三者。最平静，蓝色。

关联，一般是“moment-interval”----“role”----“party, place, or thing” ----“description”。但也存在其他关系。
另外PeterCoad在贡献出领域中立构件原型“烤箱”的同时，还不忘赠送我们用它烹调出来的12套“特定领域构件”大餐，让我们品尝。

ColorUml确实给构建企业信息系统，带了很多实用的指导。不过Domain.Driven.Design作者，领域驱动设计专家，Eric&Evans的观点，也着实让人入迷。

Eric&Evans在DDD中，明确提出了DomainModel职责层的概念。
“在深入了解一个领域之后，大模式开始显现。一些领域具有自然的层次结构。某些概念和活动依赖于其他元素，而这些元素又出于不同的原因，以不同速率变化着，我们如何利用这种自然结构，使它变得更加明显和有用呢？这种层次结构意味着分层，一种最成功的构架设计模式。”

“职责层最适合用分层模式中的“松散分层系统”来设计，它允许层，不光可以访问它的直接下层，还可以访问所有低于它的层。
因此：
仔细考虑模型中概念依赖的关系，它们的变更速率，以及导致领域各部分发生变化的来源。如果界定出了领域中的自然层次，那就把它们转化成大的抽象职责。这些职责应当描述系统的高层目标和设计。重构模型，让“领域对象”，“聚合”和“模块”适合于它所放入的职责层”

具体分层由上到下是：
Decision ----决策支持，需要执行什么和设置何种策略？使用业务活动提供的当前信息和历史信息，来分析决策，设置策略。
Policy ----策略，规则是什么？可以使用或约束低层行为。
Commitment----约束，承诺了什么？协议，合同。约束操作层，但其本身也是业务活动的结果。
Operation----操作，做什么？企业运营的核心业务活动
Potential----潜能，考虑能做什么？组织和其可用的资源。

在一般应用中，Operation层和Potential层可以放入大部分DomainObject。

比较上述两者，可以找到相似之处，“party, place, or thing”构件原型同Potential层中包含的东西，极为类似。Operation难道不是“moment-interval”么？Commitment也是“moment-interval”的一种。“description”同“specification”类似。当然，也有不同之处，ColorUml没有强调对象依赖关系的重要性。"role"在DDD中，没有突出的位置。

下面，谈谈我的想法。

根据前面的讨论和得到的规律，结合上面的论述。我们希望系统可以随着业务的变化，而同步变化。如果，我们总是试图遵循业务概念的依赖来搭建系统，那么，我们就能更直接的实现业务变化。如果，我们的系统就是按照业务的概念依赖关系，搭建起来的。那么，业务发生变化时，我能总能找到对应的变化点。按照概念依赖关系，我们知道那些对象可能会涉及到这种变化，那些对象根本不用考虑。

但正如前面提到的，业务概念的依赖关系，不会直接呈现在我们面前，我们必须采用“演化的观点”，加以提取，不断把基本概念和扩展概念进行分离。

入口，我选择能体现企业存在意义的“核心业务交互”（理论上，可以从任何一个概念入手）。这类似于前面两种方法的Operation/moment-interval。要理解加法，我们首先要对可以做加法的数有所了解。同样道理，要理解“核心业务交互”，我们首先要理解参与交互的参与者。举例来说，我们要理解生命周期较短的“购买商品”，就需要理解，谁买的？客户，谁卖的？员工，购买的是什么？商品，在哪里购买的？地点，我们得到一些依赖关系：
购买商品-->客户，购买商品-->员工，购买商品-->商品，购买商品-->地点。
要理解谁来扮演客户或员工的角色么？如果需要的话，客户-->参与者，员工-->参与者。
商品要分类么？是，商品-->商品目录。商品的定价是多少？商品定价-->商品。在不同目录里商品是同样的定价么？否，集团购买的要便宜些，商品<--商品目录定价-->商品目录。商品目录定价-->商品定价
商品有优惠策略么？有卖二送一，优惠策略-->购买商品。优惠策略有期限么？有，只在国庆节优惠，优惠策略-->日历。

“核心业务交互”也可以是生命周期较长的概念，如“协议”。协议可以由一次较短的核心业务交互产生。如：电信中的购买协议，就是通过订购活动产生的。也有把订单视为协议的，但区分订单和由此产生的购买协议，可以更好的对应实际订单和跟随订单的协议书。按照“静态依赖”规律，得到订购-->购买协议。

“核心业务交互”可以很长，也可以很短。实际上，“核心业务交互”的寿命极限可以逼近参与角色，可以认为“客户”也是一个大的“核心业务交互”，它通过“客户开户”这个瞬间“核心业务交互”而产生。

瞬间“核心业务交互”，比比皆是，通常在一个事务里处理的业务活动，都可以算作瞬间的“业务交互”。甚至，还存在，比事务还小的瞬间“业务交互”，例如：在一次“转账业务”中，可以包含一个“转出业务”和一个“转入业务”。

理解“业务交互”，是理解DomainModel的基础。可以把“业务交互”看作是连接其他概念的纽带，它本身会依赖一些基本元素，参与角色，资源，。在其上有依赖于它的协议、约束，策略和决策支持等。

我们来看一个“动态依赖”实例。
个人银行业务：
通过“挂失业务”，创建一个“挂失协议”。挂失业务-->挂失协议(静态依赖)
该“挂失协议”将影响到“取款业务”。挂失协议-->取款业务（动态依赖）

再看另外一个实例。
证券交易：
计算某笔“委托”的交易费用。费用策略-->委托（动态依赖）

可能，你已经注意到了这里有“核心业务交互”和“业务交互”，他们的区别在于，“核心业务交互”主要针对企业的外界涉众而发生的“业务交互”，是企业的核心目标。此外，还存在为了达到核心目标而需要的，支持和管理的“业务交互”，如：“用户授权”，简单的“商品入库”等等。需要注意的是，Eric Evans的职责层中的Operation应当理解为“核心业务交互”。而不是“业务交互”，考虑到Potential层产生员工的“员工开户”，也是一个“业务交互”，就不难理解我的意思。

对于企业级应用，还可能存在的依赖有：
工作流-->业务交互
工作流策略-->工作流
项目管理-->业务交互
由于，它们可能会影响到整个“业务交互”，其基础工作流引擎，基础业务规则引擎，基础项目管理构件，都需要放入底层的包中，在其之上扩展出的具体流程、规则和实际项目，将放入其依赖的具体业务交互的包里。

大体上，我接受Eric&Evans的观点，从8000公里上空来看，最下层是最稳定的“潜能”、通用业务元素和通用引擎构件，在其之上是“核心业务交互”层，它将受到施加于其上的约束、承诺层的影响，在约束和承诺层之上，是策略层，策略通过考察“业务交互”和相关的约束承诺，按照已定义的规则行事，最后，决策层负责设置这些规则。

不过，正如Eric&Evans已表达的，把它看作一个指导，而不是约束。因为，就是在同一层中，同一个包中，也要考虑对象间的依赖关系，另外，领域的自然层次结构，并不一定完全遵循这种固定的划分模式。

总之，我希望通过考察“核心业务交互”入手，建立一个带有强烈“单向依赖”倾向的积木式DomainModel，得到一种简单、明晰的优雅领域构架，它反映了领域的自然分层结构，因而，能从容应付业务当前和未来的发展变化。

我一直也对OO Model很有兴趣，希望从中发现四两拨千斤的关键要素。只是不知如何下手。

Analysis Pattern
Data Model Resource Book
UML Color Model
Data Model Essential

这些书也都阅读过，觉得很难啃。作个参考书还差不多。做入门进阶还不行。因为书中列出的大部分都是Facts, What，而不是Why, How。

Partech贡献了OO Model方面的很多好文章。孜孜不倦地探索Why, How这些原理方面的东西。只是有些偏概念化，可操作性不强。
Partech收了一个fans， yimlin。貌似理解颇深。也写出了不少强文。虽然如同Partech老大的OO Model一样，曲高和寡，无人问津。:D

最近虽然没做什么东西。但是却也遇到不少挫折。被迫思考了一些问题。

用到深处，OO和FP有些异曲同工，殊途同归。
比如，Partech写过不少职责划分的文章。对于职责划分，有些OO Extremer有这样的观点，一个Object只做一件事情，其余的事情交给delegate去做。采用的Pattern是Proxy, or Delegate。
这也反映了FP的一些观点。只是实现方式不同。FP基本都采取Factory of Factory, Generator of Generator这样的Pattern来实现，一个Function只完成一件事情。一个Function通常是返回另一个Function。

另外一个是ajoo说的，FP / 组合子注重高阶逻辑，组合子之间的亘古不变的关系。这个也部分地反映在OO Model中。


对于关系关联，OO 和 FP 的做法有很大不同。
根本的不同在于，FP 里面的关系关联，是形式定义的，是显式的，是可以被语法分析器识别的。
而OO的关系关联，是运行时期构造的Object Reference，而不是形式定义的关系，无法被语法分析器识别。

对于这个
//
该“挂失协议”将影响到“取款业务”。挂失协议-->取款业务（动态依赖）
//
应该是

该“挂失协议”将影响到“取款业务”。取款业务-->挂失协议（动态依赖）

这样吧

UML Color Model 实用的很

就我目前的认识来看，FP之所以在实际开发中少有作为，主要问题在于FP依赖于公式计算，但实际项目中面对的需求，却不能很好的作出这种抽象，即使有，也会过于复杂。如果没有这种公式级别的抽象，FP就成巧媳妇了。


示例比较少是因为，我觉得大家都有自己熟悉的领域，假如具有普遍规律，基于对自己熟悉的领域的思考，应该会有些共同的认识。
另外，不管是使用java还是ruby，同样存在DomainModel结构的问题，这是领域本身的问题，同语言关系不大，所以，俺愿意继续这方面的探索，至于Ruby，俺是在等着摘成熟的果子哩。

FP的主要阻力在于嵌套层次太深。
OO里面可以用Flat结构的顺序语句做的事情，FP就需要用Nested Closure （Nested Factory, Nested Generator）来做。
Nested结构肯定要比Flat顺序结构难以理解。

来看看到底谁依赖谁？
取款服务，在没有“挂失协议”时，你可以想象是在大同世界，即使卡丢了，也不必担心，取款服务是完整的。
但是，现实世界太不理想。居然有冒取的情况发生！所以需要提供“挂失协议”，协议本身的含义就是要限制所有的帐户操作，也就是说在理解“挂失协议”时，不能离开“取款”，“存款”，“改密码”等等操作。所以，依赖关系是:挂失协议-->取款业务。

buaawhl太过奖，理解不敢说深，连貌似都不敢说是。
只是想扔一个砖头，等着看牛人们的金玉呢:D
大约是这块内容不太好举例，和业务领域背景有点关系，牛人们都惜字如金。

BTW：嘿嘿，最近在blog中打着你的旗号招摇过市呢！见谅见谅！