DCI的核心思想：
- 对象扮演某个角色进入场景，然后在场景中进行交互，场景的参与者就是对象所扮演的角色；
- 一个对象可以扮演多个角色，一个角色也可以被多个对象扮演；
- 对象的属性和行为分为：A：核心属性和行为，这些属性或行为是不依赖于任何场景的；——这部分相当于是基础,固定不变，与变化隔离。B: 场景属性和行为，对象通过扮演某个角色进入某个特定场景时拥有的属性或行为，一旦对象离开了这个场景，不再扮演了这个角色后，这些场景属性或行为也就不再属于该对象了；比如人有核心的属性和行为：身高、体重、吃饭、睡觉，然后当人扮演教师的角色在教室里上课时，他则具有上课的行为，一旦回到家里，就又变成了一个普通的人；比如一个物品，在生产时叫产品，在销售时叫商品，坏了的时候叫废品，它在不同阶段扮演不同的角色所具有的属性是不一样的；——这部分相当于是基础的扩展,是场景特有的。
- 场景的生命周期，场景是一个时间与空间的结合，可以理解为某个活动；一旦活动结束，则场景也就消失；
- DCI中的D可以理解为DDD中的领域模型；场景中交互的是角色，而不是领域实体。场景属于DSL的思考层面，更接近于需求和用例。而领域也是伟大的出现，但是不能为了领域而领域，为什么呢？因为场景是大哥用例是大哥。领域的存在是为了控制固定概念的部分，这样在某种成度上控制了一定的复杂性和提高了可控性，而DCI则解决了可变性和需求的问题。从某种意义上来说，“领域层（在DCI中可能不会太凸显领域层，不如OLD DDD那么凸显）” 是为了DCI架构服务的。
- 角色是人类的主观意识，用于对象分析和设计阶段，但是在运行阶段，角色和对象实体是一体的，软件运行过程中只有对象，只是这些对象在参与某个活动时扮演了某个角色而已；
领域驱动设计中的对象设计部分的一些要点：
-
DDD的在对象设计方面的最大贡献之处在于其实体、值对象，以及聚合边界的三个部分，通过这三个概念，我们可以将对象的静态结构设计好。
- 领域对象所包含的属性必须是只读的，只读的含义是一旦对象被创建好，则只有对象自己才能修改其属性，属性的类型可能是基本数据类型或值类型，即ValueObject；
- 领域模型设计时不应考虑ORM等技术性的东西，而应该只专注于业务，不要让你的领域模型依赖于技术性的东西；
- 领域对象的属性和方法设计时要完全根据业务的含义和需要来进行，不要动不动就把每个属性定义为get;set，这会导致领域模型的不安全;
- 仓储（Repository）不是解决让领域模型不依赖于外部数据存储的唯一方式，我觉得还有更优雅的方式那就是事件驱动；
- 设计领域模型时不要考虑分层架构方面的东西，因为领域模型与分层架构无关；
- 不要认为领域模型可以做任何事情，比如查询。领域模型只能帮你处理业务逻辑，你不要用它来帮你做查询的工作，那不是它擅长的领地，因为它的存在目的不是为了查询；CQRS的思想就是指导我们：命令和查询因该完全分离，领域模型适合处理命令的部分，而查询可以用其他任何的不依赖于领域模型的技术来实现，甚至可以直接写SQL也可以；
- 分析领域模型及其对象之间的交互时，要分清什么是交互的参与者，什么是交互的驱动者，通常情况下，比如人是交互的驱动者，而人在系统中注册的某个帐号所扮演的角色就是交互的参与者；比如我用A的图书卡去图书馆借书，则我是借书活动的驱动者，而A的图书卡对应的帐号所扮演的借书者（Borrower）角色就是借书活动的参与者；
DDD能够指导我们建立一个静态的领域模型，该领域模型能够清楚的告诉我们建立出来的对象“是什么”，但是DDD却不能很自然的解决“做什么”的问题。大家都知道DDD在对象设计的部分实际上是一种充血模型的方式，它强调对象不仅有属性还会有行为，如果行为是跨多个领域对象的，则在DDD中用领域服务解决。但是DDD却没有完整的考虑对象与对象之间的交互如何完成，虽然它通过领域服务的方式协调多个对象之间进行交互或者在应用层协调多个对象进行交互。但是在DDD中，对象往往会拥有很多不该拥有的属性或行为。
补充说明：
1.编码设计要抽离出那些固定不变的部分，让可变的部分成为其扩展——这样就能提高代码的重用和灵活性,降低需求的变化对代码的影响(改动)。
2.场景决定了(对象的)角色，领域依托于场景。脱离的角色，谈角色就没有任何意义！
以上是最近学习的简单整理，文中的主要内容转载于http://www.cnblogs.com/netfocus/archive/2011/07/10/2102099.html，仅在文中做了了自己的理解，希望此文能对你有所启发！
