OO世界里的DomainModel，相对其他人工创造的领域来说有它的优势，大部分DomainObject在现实世界都能找到原型。通过分析现实世界的原型，我们能得到足够多的原始材料。

  在构建企业信息系统时，我们希望构建出的系统，在高效正确运行的同时，构架容易理解，易于扩展。我认为要做到这点，必须要满足后面的条件--系统构架须同领域存在一致的演化映射。领域基本概念就是系统的基本对象，在领域基本概念上，演化的扩展概念，系统必须要以扩展方式，实现它们，扩展对象需关联其基础对象，而不能相反。如果不满足这个条件，则系统构架和领域间将存在不匹配情况，并且其上发展的概念的映射也将受到影响。
 
  所以我们首先要考查领域概念的演化关系。一旦我们确定了这种演化关系，那么DomainModel很大程度就是简单的一一映射问题。不过由于领域的概念，多半都是同时，而并不是按照演化的方式呈现在我们面前。我们有必要整理一番。“如果不研究中国的历史，就没法理解中国的现状”，同样，“如果不研究领域概念的演化，也就没法理解领域模型的结构”。

“世界就是相互作用的总和”，对于企业活动也可以这么看。企业活动，必然存在参与者，包括，资源提供方--目标组织及其价值供应链和资源消费方--客户。也必然存在他们之间交换的资源，可以是物，商品、器材、书、证券等；也可以是某种服务，保险、租赁、上网、访问权限等。所以，基本的业务概念，就是“参与者”、“资源”和“业务交互”，而“业务交互”依赖于“参与者”和“资源”。简单来说，企业信息系统就是要解决“参与者间，围绕资源进行业务交互”的自动化问题。

  考查一个券商证券交易系统的示意版本，最基本的参与者是:客户、员工、证券公司、交易所。最基本的资源是证券交易服务。为了完成证券交易服务，还需要属于客户的保证金帐户和证券帐户。证券帐户要知道自己使用哪个保证金帐户来清算，另外证券帐户将依赖于交易所子域中交易市场。交易市场必须要知道自己属于哪一交易所。
证券交易委托-->保证金帐户，证券交易委托-->证券帐户，证券帐户-->保证金帐户
保证金帐户-->客户，证券帐户-->客户
证券帐户-->交易市场，证券帐户明细-->证券，证券-->交易市场，交易市场-->交易所
这里引入一个重要问题，对于对象间的关联，我们到底如何确定它们的依赖和导航关系？似乎证券帐户-->证券交易委托,客户-->保证金帐户，客户-->证券帐户，交易市场-->证券，交易所-->交易市场，也是合理的依赖和导航关系。为什么我们不建立呢？我的回答是“这种方向的依赖关系，背离了领域概念的演化规律”。让基本概念依赖于扩展概念，将导致基本概念不稳定。要使我们的领域概念稳定，必须要做到基本概念不随着业务的发展而改变。也就自觉的遵守了“开闭原则”。

  业务概念的依赖分两种。一种是--“静态依赖（持久依赖）”，另一种是--“动态依赖（短暂依赖）”

  “静态依赖”-- 要划分静态关联的基本概念和扩展概念，有一个简单有效的方法，那就是比较它们的生命周期，生命周期长者为基本概念。理由很简单，因为两关联概念生命周期不同，必存在生命周期长者在某个时间段，没有生命周期短者同它关联而独自存在。

扩展概念：      |---------------|
基本概念：  |--------------------------------|

“动态依赖”--对应UseCase中的扩展关系。例如：电信应用中价格策略同产品订单的关系，价格策略根据客户购买产品的订单，来施加业务规则，虽然，价格策略的生命周期要比单个订单长，但扩展概念却是价格策略，订单到成了基本概念。“动态依赖”的识别规律，在UseCase建模中，已经给出--“扩展是基本的可选部分”。

不管是“静态依赖”扩展，还是“动态依赖”扩展，都满足“基本概念可以独立于扩展概念存在，反之则不然”的特征。

  虽然，上述的结论来源于我所经历的几个特定领域，但我相信它同样适合于其他的企业信息系统。当然，这需要得到印证。