1、 架构设计时，需要将软件的高层业务逻辑与底层的技术实现（如UI、数据库、I/O操作等）隔离开来。前者较为稳定，后者容易变化。在设计阶段，应尽量多地考虑高层的业务逻辑，将涉及技术实现的决策尽量向后推移。
2、 系统应按照用例来划分成不同模块，因为不同的用例在未来往往有不同的变更时间和变更原因。系统的主要用例应该在其系统结构上清晰可见。用例是描述业务逻辑的，不应涉及用户接口这样的细节。
3、 一个良好的软件架构从逻辑上大致可以分为用例（流程性业务逻辑）、业务实体（原子业务逻辑）、接口适配器（从抽象到具体的桥梁）、框架与驱动程序（具体技术实现）四个层次，底层依赖于上层，而不能反向依赖。
4、 可测试性是软件的一种重要特性，在软件设计时就要做充分考虑。测试组件实际上是最下层的程序，依赖于被测试代码。
5、 一个良好的软件架构应当能独立于其所使用的程序框架、数据库、UI等技术实现细节，并且具有可测试性。
无依赖环原则
循环依赖会导致”一觉醒来综合征“，导致开发、测试、发布和维护的困难。
采用DIP打破既有组件的循环依赖；或者创建新的组件。
典型的组件结构图
组件结构图是不可能自上而下被设计出来的。它必须随着软件系统的变化而变化和扩张，而不可能在系统构建的最初就被完美设计出来。
因为组件依赖结构图并不是用来描述应用程序功能的，它更像是应用程序在构建性与维护性方面的一张地图。随着早期被设计并实现出来的模块越来越多，项目中就逐渐出现了要对组件依赖关系进行管理的需求，以此来预防“一觉醒来综合征”的爆发。除此之外，我们还希望将项目变更所影响的范围被限制得越小越好，因此需要应用单一职责原则（SRP）和共同闭包原则（CCP）来将经常同时被变更的类聚合在一起。随着应用程序的增长，创建可重用组件的需要也会逐渐重要起来。这时CRP又会开始影响组件的组成。
如果我们在设计具体类之前就来设计组件依赖关系，那么几乎是必然要失败的。因为，组件依赖关系是必须要随着项目的逻辑设计一起扩张和演进的。
稳定依赖原则(SDP)
依赖关系必须要指向更稳定的方向。稳定性应该与变更所需的工作量有关。对于软件来说，带有许多入向依赖关系的组件是非常难修改的，也就是非常稳定的。一般带有很多出向依赖的组件是易修改的，也就是非常不稳定的。
I：不稳定性，I=Fan-out/（Fan-in+Fan-out）
Fan-in：入向依赖，这个指标指代了组件外部类依赖于组件内部类的数量。
Fan-out：出向依赖，这个指标指代了组件内部类依赖于组件外部类的数量。
该指标的范围是[0,1],I=0意味着组件是最稳定的，I=1意味着组件是最不稳定的。
稳定依赖原则（SDP）的要求是让每个组件的I指标都必须大于其所依赖组件的I指标。
稳定抽象原则(SAP)
一个组件的抽象化程度应该与其稳定性保持一致。
如果一个组件想要成为稳定组件，那么它就应该由接口和抽象类组成，以便将来做扩展。如此，这些既稳定又便于扩展的组件可以被组合成既灵活又不会受到过度限制的架构。
A：抽象程度，A=Na÷Nc。
Nc：组件中类的数量。Na：组件中抽象类和接口的数量。
A指标的取值范围是从0到1，值为0代表组件中没有任何抽象类，值为1就意味着组件中只有抽象类。
将SAP与SDP这两个原则结合起来，就等于组件层次上的DIP。因为SDP要求的是让依赖关系指向更稳定的方向，而SAP则告诉我们稳定性本身就隐含了对抽象化的要求，即依赖关系应该指向更抽象的方向。
持续补充。。。。。。
出自《架构整洁之道》
