原创作者: partech
阅读:2144次
评论:0条
更新时间:2011-05-26
第一次接触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，得到一种简单、明晰的优雅领域构架，它反映了领域的自然分层结构，因而，能从容应付业务当前和未来的发展变化。
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，得到一种简单、明晰的优雅领域构架，它反映了领域的自然分层结构，因而，能从容应付业务当前和未来的发展变化。
评论 共 0 条 请登录后发表评论
您还没有登录,请您登录后再发表评论