对象的粒度到底是多大？这没有一个统一的规律，哪些属性或行为属于A对象，哪些属于B对象，有时又需要将这些属性和行为分离以便能够灵活组合。我们一般很难确定类的粒度到底是怎样规模表示达到设计目的？

　　首先，粒度不能太大，造成重复和冗余，很多概念混在一起；当然粒度也不能太细，以至于太碎，不能完整表达一个领域概念，例如半个铀原子就不再是铀。

　　类需要尽量准确表达领域概念，大多数领域中都包含某种逻辑上的一致性，而很多程序员有时只注意单纯的设计原则，忽视领域逻辑，设计思考时需要两条腿走路，实现平衡，比如JdonFramework的缓存设计主要应对企业领域大量查询都是在时间上相对集中的查询（如本月度），因为领域中某种逻辑存在(时间上相对集中的查询)，才使得我们决定采取某种设计方案，如果没有这个前提，任何设计方案都是可行的，这也是我们通常讨论的业务场景。

　　每个人对业务领域中很多概念都可能不一致，但不能否认：领域中一定在某个地方存在一种旋律，我们的模型肯定能够与领域某个部分发生共振，问题关键是：我们需要通过不断发现的过程来寻找这种共振，这过程就依赖反复的重构重整refactoring。

　　通过重构，使我们的设计适应我们重新理解了的领域概念和业务需求，概念轮廓(Conceptual Contour)就会浮现。

　　注意“概念轮廓”是指对领域中概念的主要轮廓，大概样子，需要忽视不重要的细节，设计人员必须理解领域中概念在哪些地方会发生改变？哪些地方保持相对稳定，然后使设计的模型尽量与领域中概念稳定面结合起来，这样，当业务领域中概念发生变化时，我们的模型才会随之一起翩翩起舞，发生共振，从而达到模型设计反应领域本质的目的。

　　所以，类的粒度是要能够反应领域的概念轮廓，将能够反应概念轮廓的那些重要元素聚合到当前正在设计的类中，这也是设计中高聚合原则的体现。

　　高聚合、低关联是两个设计基本原则，上面我们谈了如何做到高聚合，实际上，也是反映一种类或模块的粒度设计规模。下面谈谈低关联：

　　消灭依赖

　　复杂的依赖关系无疑提高了系统的复杂性，加剧我们大脑负载，所以，我们的模型之间关系必须精练，减少依赖，最后保留下来的依赖代表了领域概念之间某种根本的关系。有的系统中，甚至是0关联，从而得到一个个被完全孤立的单独的类(standalone Class)，这才是方向（也有利于我们简化配置Hibernate这些模型持久化框架，无需考虑一对多等关联配置）。

　　每个依赖都是值得怀疑的，这是我们思考的前提，重构时，一个个去消灭那些象蜘蛛网一样密集的关系，斩断它们，低关联时减轻概念过载问题的基本方法，孤立类是低关联达到极致的一种标志。

　　减少依赖不是意味不考虑业务领域场景概念，武断实现，依赖和之前描述的边界影响一样，有时确实不能消灭，那么我们就承认它，但是会又有一套设计原则来约束它。