借一句古语当引子：止而后有定，定而后能静，静而后能安，安而后能虑，虑而后能得！

从大粒度下看，模型会分解成两大块：

1. 静态特征：domain 大体从描述业务数据开始进行驱动；

2. 动态特征：service 大体上是业务操作的集合，形成服务层。

有些操作会放在domain的类中， 那是常常是因为，数据与操作的生命周期都要受同一个对象生命周期的限制; 而有很多操作方法会放在service层类中， 那常常是因为， 数据与操作的生命周期不拘束在一个对象生命周期中，使用灵活,而且这些类型本身就是方法的集合，适合提炼出接口，做好层与层之间的分离。

从小粒度去看，类分为两大块：

1. 静态特征： 属性(数据)

2. 动态特征： 方法(操作)

考察属性和方法如果分离，就意味着数据与操作朝着各自更抽象更灵活的方向去发展，尤其方法，它适用数据的范围更广，重用性更强，继而演化或沉淀出方法(更大粒度看服务)不变，而应对千变万化的业务数据的架构来...

[该贴被youway于2010-04-21 23:57修改过]

DDD的那本书，继续看下去，现在看到service，module，这些东西还是比较浅的，还要继续下去

如各位所言，不管是实体还是值对象，还是service，这些对象之间的业务区分不是非常明显，尤其是没有经过业务证明，就不是非常好区别

Antinomy 正解。

DDD是一种介于分析与编码之间的工具，要让分析与设计互相影响，同时不失去对系统业务核心的理解。

说说我的想法，值对象不一定是无职责的对象。我目前判断值对象和实体的时候，主要是看是否需要跟踪，以及对象是否有独立的生命周期。如果一个对象有自己独立的生命周期，那么我觉得它就属于实体对象。

至于聚合跟的问题，我觉得这里也涉及到了封装和粒度的问题。我们涉及讲究对外封装，对内解构，当一个实体的行为变得太多的时候，我们势必要对其细粒度化，使得不同的对象负责不同的行为，但是细化以后，我们还需要封装，这就需要聚合跟了，聚合跟不仅要封装对子对象的访问，也要协调子对象来完成业务操作。

至于service等的，这其实还是与状态有关系，而我们的系统中一般存在两种状态，无状态和有状态，无状态的一般是service组件，或者一些技术性质的组件，而有状态的就是领域模型，因此这里就涉及到了生命周期管理的问题，无状态组件我们让容器管理，而领域模型需要我们自己手动管理，而我们要想管理生命周期，那么我们是必要先封装好对象的状态，因为整个生命周期中，我们所做的也就是对状态的跟踪。