面向模式构建系统架构的反思

1、构建系统架构的基础是用户需求及对于业务流程的用例(use case)，可以采用Commonality/Variability（公共性/可变性）分析。它的核心思想是针对问题领域中的概念进行分类，把那些看上去不同但本质上属于一类的概念用一个抽象的概念来表示，然后基于这些抽象的概念构建架构。

2、架构应能对于进一步工作提供指引，架构不能过于空泛，缺乏延伸性。架构同时不能过于抽象，显的空泛从而指导意义不大、或过于具体，陷入细节从而失去通用性。

3、面向对象的设计原则－类设计原则：
开闭原则（the Open Closed Principle OCP）：一个模块在扩展性方面应该是开放的而在更改性方面应该是
封闭的。
替换原则 (the Liskov Substitution Principle LSP)：子类应当可以替换父类并出现在父类能够出现的任何地方
依赖原则 (the Dependency Inversion Principle DIP)：在进行业务设计时，与特定业务有关的依赖关系应该尽
量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与
特定业务有关的依赖关系。为此，我们在进行业务设计时，应尽量在接口或抽象类中定义业务方法
的原型，并通过具体的实现类（子类）来实现该业务方法，业务方法内容的修改将不会影响到运行
时业务方法的调用。
接口分离原则（the Interface Segregation Principle ISP）：采用多个与特定客户类有关的接口比采用一个通
用的涵盖多个业务方法的接口要好。这个原则的本质相当简单。如果你拥有一个针对多个客户的
类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所
需所有方法有效。
单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因。在构造对象时，将对象的
不同职责分离至两个或多个类中，确保引起该类变化的原因只有一个。带来的好处：提高内聚、降
低耦合。

4、设计模式的层次认识：
1）、第一层境界：认为模式就是一种解决方案
2）、第二层境界：除了解模式提供的解决方案以外，还能够认识到模式背后的一些指导原则，如针对
接口编程；优先使用组合而不是继承；发现变化、封装变化；
3）、第三层境界：认识到模式其实是一些关系，用来舒缓系统内部的"冲突力"。