总的来说是高内聚低耦合，内聚是把变化点进行封装，耦合还是要有的，只是要尽量少，不同内聚点的联系方式有两种，一种就是继承，一种就是组合。组合又分为基于接口组合还是基于类组合，基于接口就可以灵活的改到聚合点的实现，只要符合接口的规范就可以。
（一）抽象
现实世界和程序对象之间的映射关系。不是像（相似）建模，是要对解决的问题进行抽象建模，要解决的问题是可能发生改变的，所以组织对象的时候要考虑把可能的变化封装起来。这件事很重要，怎么把现实问题一步步映射成对象，再到代码的经验，就是领域驱动建模了。
（二）封装变化
业务在不断变化，，想要程序可以持续使用，就要在需求变化时容易改变程序。可以把变化的东西抽成一个方法，或者抽成一个类，取决于粒度。这样同一个变化点以后改起来只要改一个地方就好。如果变的动静可能会很大，比如可能会把整个类都替换掉，可以把这个类提供的服务抽象成个接口，就可以满足开闭原则，对扩展开放，在修改关闭，设计模式就是封装变化或者是满足开闭原则的经验。
封装，接口。
编码：抽象成方法，如果是重要的领域概念，抽成类。再灵活些抽成接口。模式提供了一些封装变化的模板，如策略，模板方法。
开发管理：同样的东西不要重复实现，引用一处，变更容易。（如UI部门选择树，以及从业务模块接口）
架构：模块间重复的逻辑，可以抽出基础平台。
实现：第一步是对变化封装。更进一步抽象化是关键，更灵活的扩展。
封装变化有两种类的形式，一种是继承一种是组合。
（三）（is a）里氏代换原则
任何基类可以出现的地方，子类也一定可以出现。。
（四）合成优于继承
是抽象，合成比继承在大部分情况下更适用，和里氏相辅，是实施规范。
| 原代码程序设计 |  | 知识点： 1组合和继承 2在同一层次减少包装类（包装类有为想跨层时才有用） 3.更多可用的接口 4.太深的层次 5.应用的灵活性(比如应用可以根据自己的需求要不要向上层暴露底层是分库分表的，有些业务可能需要知晓分库分表-按分表做一些线程划分，有些应用不需要-查询一些数据不关心这些数据都在哪些表里) |
| 新的设计 |  |
（五）基于接口（依赖倒转原则）
要依赖于抽象不要依赖于实现。开放封闭原则是目标，依赖倒转原则是手段。
A依赖调用B,A调用a1接口,B实现a1接口。从而B依赖于a1。
（六）单一职责
类，方法，变量都只做一件事，要不名字都没办法起。
不用看类的实现，只看类名，就知道类做什么；不用看方法实现，只看方法名，就知道方法做什么。（注：最多加上注释，所以引出注释的程度就是要和名字一起让别人不用看实现就可以放心的使用它）引出了单一职责。
（七）接口隔离原则
不要提供大的总接口。是单一职责的子集。
每个类，或者方法都应该尽可能少的对外提供服务，这样产生对象改变的原因就会单一，是封装变化的一个更好的保证，变化封的更严实。
软件要能灵活适应变化，组件化，组件可替换，基于接口。
（八）最小可见性（迪米特法则）
一个软件实体应该尽量少的和其它实体发生相互作用。通向开闭原则的道路。调用方调用够用就可以，被调用方暴露尽量少的服务。
