领域对象的生存之道

1.领域对象的独立性？？？
  dao，网络，UI，事务，文件操作等等。。。。
  领域对象上面是UI 下面是dao，文件，事务，等辅助类。基础类。
  如何做到干干净净？？？
2.分层策略对领域对象的独立性有多大好处，层之间的沟通原则？？
3.设计模式对领域对象的独立性有多大好处，怎么用设计模式不多不少正好？？？
4.服务的概念对领域对象的独立性有多大好处??
  服务是更多对象的链接点。依附于那个对象都不合适。
  服务和领域对象的操作，方法，如何取舍？？？
  有状态的服务，和无状态的服务?
  领域的服务，和基础层的服务。
5.业务在哪儿呢？？？
  我们的系统业务无处不在，ui，服务层，dao，存储过程。。。。
  把业务全都放到领域对象里面。
  ui，dao，存储过程，服务层，简化，原子，无业务关联。
6.高内聚，低耦合，模块化，组件化。
  通信性内聚。
  功能性内聚。
7.模块之间沟通的问题。
  概念：聚合根。模块的引用入口。
  模块之间沟通：对聚合根进行变更。或是让聚合根执行某些动作，沟通只有这两种模式，
  绝对不允许，模块中的一部分不经过聚合根直接和别的模块沟通。
8.聚合根的生成（工厂）。
  由于聚合根是多个对象，服务，交叉，高内聚的产物，联系繁多复杂。
  所以，工厂是一个生成聚合根的绝佳方法。

后续还有，我现在正在看领域驱动设计这本书，收益良多啊。
每做完一个项目，再拿出这本书翻翻，总结项目进行时，自己的思路，和书本上的理论的碰撞。
对自己又是一次提升。
欢迎大家讨论。

层次清晰，职责分明是方向不是目的

看了后，你会感觉没什么用，上面说的太理想了，和实际不符合

xuyao 回复
看了后，你会感觉没什么用，上面说的太理想了，和实际不符合.
我发表一下我的感触。
1.我们所谓的软件99%都是以数据为中心的管理应用系统，这个是不是领域对象的应用真空？？？？？？？？
2.取其精华，弃其糟粕，DDD的精华是那部分？？？？