|
|
好久没有写文章了，最近比较忙，另一方面也是感觉自己在这方面没什么实质性的突破。但是今天终于感觉自己小有所成，有些可以值得和大家分享的东西，并且完成了两个可以表达自己想法的Demo。因此，趁现在有点时间，是写文章和大家分享的时候了。
首先给出这两个Demo的源代码的压缩包的下载地址，因为之前有博友说他没有装VS2010而没办法运行Demo，所以这次我分别用VS2008和VS2010实现了两个版本。
http://files.cnblogs.com/NETfocus/DCIBasedDDD.rar
下面先分享一下我最近研究的一些知识及我对这些知识的自我感悟，然后再结合Demo中的示例讲解如何将这些感悟应用到实际。
一、理论知识：
我最近一直在学习下面这些东西：
- 面向对象分析与设计，即Object Oriented Analysis and Design（OOA/D）
- 领域驱动设计，即Domain Driven Design（DDD）
- 四色原型：MI原型、Role原型、PPT原型、Description原型
- DCI架构：Data Context Interaction
- CQRS架构： 命令查询职责分离原则，即Command Query Responsibility Segregation
通过学习以上这些知识，让我对面向对象的分析、设计、实现有了一些新的认识。
1. 碰到一个业务系统，我们该如何分析业务，分析需求，并最后得到一个只包含业务概念的模型？答案是通过四色原型进行业务建模。四色原型的中心思想是：一个什么什么样的人或组织或物品或地点以某种角色在某个时刻或某段时间内参与某个活动。 其中“什么什么样的”就是DESC，“人或组织或物品或地点”就是PPT，“角色”就是Role，而”某个时刻或某段时间内的某个活动"就是MI。更具体的说明请参看我之前整理的一篇文章：四色原型的学习心得分享
2. 业务模型建好了，该如何通过面向对象的分析与设计方法来进行对象建模呢？ DDD和DCI思想可以帮助我们。首先，DDD能够指导我们建立一个静态的领域模型，该领域模型能够清楚的告诉我们建立出来的对象“是什么”，但是DDD却不能很自然的解决“做什么”的问题。大家都知道DDD在对象设计的部分实际上是一种充血模型的方式，它强调对象不仅有属性还会有行为，如果行为是跨多个领域对象的，则在DDD中用领域服务解决。但是DDD却没有完整的考虑对象与对象之间的交互如何完成，虽然它通过领域服务的方式协调多个对象之间进行交互或者在应用层协调多个对象进行交互。但是在DDD中，对象往往会拥有很多不该拥有的属性或行为。在我学习了DCI架构之后，我认识到了DDD的很多不足。
以下是DCI的核心思想：
- 对象扮演某个角色进入场景，然后在场景中进行交互，场景的参与者就是对象所扮演的角色；
- 一个对象可以扮演多个角色，一个角色也可以被多个对象扮演；
- 对象的属性和行为分为：A. 核心属性和行为，这些属性或行为是不依赖于任何场景的；B. 场景属性和行为，对象通过扮演某个角色进入某个特定场景时拥有的属性或行为，一旦对象离开了这个场景，不再扮演了这个角色后，这些场景属性或行为也就不再属于该对象了；比如人有核心的属性和行为：身高、体重、吃饭、睡觉，然后当人扮演教师的角色在教室里上课时，他则具有上课的行为，一旦回到家里，就又变成了一个普通的人；比如一个物品，在生产时叫产品，在销售时叫商品，坏了的时候叫废品，它在不同阶段扮演不同的角色所具有的属性是不一样的；
- 场景的生命周期，场景是一个时间与空间的结合，可以理解为某个活动；一旦活动结束，则场景也就消失；
- DCI中的D可以理解为DDD中的领域模型；场景中交互的是角色，而不是领域实体。场景属于DSL的思考层面，更接近于需求和用例。而领域也是伟大的出现，但是不能为了领域而领域，为什么呢？因为场景是大哥，用例是大哥。领域的存在是为了控制固定概念的部分，这样在某种成度上控制了一定的复杂性和提高了可控性，而DCI则解决了可变性和需求的问题。从某种意义上来说，“领域层（在DCI中可能不会太凸显领域层，不如OLD, DDD那么凸显）” 是为了DCI架构服务的。
- 角色是人类的主观意识，用于对象分析和设计阶段，但是在运行阶段，角色和对象实体是一体的，软件运行过程中只有对象，只是这些对象在参与某个活动时扮演了某个角色而已。
3. 领域驱动设计中对象设计部分的一些要点：
- DDD的在对象设计方面的最大贡献之处在于其实体、值对象，以及聚合边界的三个部分，通过这三个概念，我们可以将对象的静态结构设计好。
it知识库：分享一些如何分析和设计具有动态行为的领域模型的经验，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
