1.场景类（业务逻辑类）的扩展用继承，工具类的扩展用组合。相对而言。别人的核心业务，到自己那里就成了工具。所以一般不继承程序集的类，除非特别说明。
场景类可能比较复杂，这里会更倾向于用继承。工具类专注于具体的方法，将逻辑上联成一体的功能逻辑，效率优化到极致。
2.工具类适合单一职责，场景类的职责就是调用，起到一个框架的作用，核心的作用。
其他层封装的是具体某一块，场景类封装的是业务流程，在工具之间起到胶水和填充的作用，做各种杂事，用继承来描述复杂多变的业务逻辑，适应变化。
3.继承树子类如果有大量的兄弟，应确保对类别的抽象是逐渐具体化的，即父类同辈兄弟的数量应小于子类同辈，子类应是很少扩展代码，大部分继承自父类的合理抽象。
父类调用子类功能，也可能反之，子类定义父类调用， 抽象链条与调用链条不匹配，应使用抽象方法。
因为最终的场景架构是组合，组合不一定分层，但是应用层和基础设施层向领域层前进的过程，实际上是对具体问题不断抽象的过程。
应以抽象程度为线索构造继承树。继承的起点到终点通常在组合的同一个层，父类只有更抽象才能解决更广泛的问题，以充分实现重用的目的。重构和设计的时候，应尽可能对方法确立接口，而不是对属性和字段确立接口。属性和字段确立的接口是一种深层的捆绑，很难发生变化的，好处在于可以写尽可能通用的方法，在父类完成统一的功能，一般这种设计不能依赖某种简便思路的合理推导，一定要在领域模型的高度判断，这些同样接口的类具有功能和概念上的长期一致性，否则一旦需求变化，有的有通用接口，有的要用另一套方法，不能从概念上自成体系，自我解释，反而叠床架屋，增加复杂性。
4.继承可以是一种分层，每一层完成不同的功能（或抽象），最终产生一个强大的功能。
组合也是一样的，如果被用于分层，则实际上是对底层的封装和抽象，如果被用于框架，则是对某个领域的封装。
继承和组合的区别在于是否组装出一个强大的单一类，视系统的领域架构，逻辑架构而定。
场景类继承产生场景类，工具类组合产生工具类，构成场景之网的网点，机器的构件。如果必须对完整功能的工具类进行继承，说明搞错了，要么工具类设计有瑕疵，要么场景类构思太贫血。
如果场景类方法超过上千行，或是一个程序集里出现多个独立继承树的场景类，工具类，程序员在类型名字设计上出现障碍，后来者很难搞懂，说明场景类的继承功能尚未发挥到极致。 一个程序集只应有一个主继承树，如果有多个，那么做多个程序集。工具类不应当被继承，如果需要，另外定一个领域，将其作为场景类独立设计，然后在更大的场景类中当工具，或是构成工具类的构件来调用。
继承对基类的逻辑领域整体不动，只有调用，如果必须要动，且造成原设计面目全非，则可能继承树选错了，或不该用继承。
5.继承应慎用虚方法和覆写，应确保覆写的方法是一个完全独立的方法，对父类同层的成员很少依赖（其他成员可以依赖它，它应是一个被调用者）
6.分层也好框架也好，继承也好组合也好，划分的标准实际上是对领域边界的理解，领域实际上是做什么事的，他的边界在哪儿？
例如前述完整的工具类，到底完整是什么定义？
在如工具类的扩展用组合，扩展的定义是什么，假如你能改每一层工具类源码，那么什么时候去改工具类，改哪一层，什么时候去改场景类？
领域使系统架构清晰高效，其他概念是用来描述领域的方式，并非硬性标准。