《架构整洁之道》阅读笔记03

接着上一次的《架构整洁之道》阅读笔记02继续写最后一篇：

10.插件式架构

1.软件开发技术发展的历史：就是一个如何想法设法方便地增加插件，从而构建一个可扩展、可维护的系统架构的故事。

2.系统的核心业务逻辑必须和其他组件隔离，保持独立，其他组件要么可以去掉的，要么有多种实现的。

 

11.业务逻辑

业务逻辑是一个系统存在的意义，属于核心功能，是系统用来赚钱或省钱的那部分代码，是整个系统中的皇冠明珠。

业务逻辑应该保持纯净，不要掺杂用户界面或者所用数据库相关东西。

理想情况下，代表业务逻辑的代码应该是整个系统的核心，其它底层概念的实现应该以插件形式接入系统中。

业务逻辑应该是系统中最独立、复用性最高的代码。

 

12.整洁架构

常见系统架构，六边形架构（端口与适配器架构）、DCI架构、BCE架构。

1.分层：这些架构都会将软件切割成不同的层，至少有一个层是只包含软件的业务逻辑的，用户接口、系统接口属于其他层。

2.代码依赖只能使由外向内，内层结构的代码不能包含有任何外层结构的信息

每一种架构一定能在写系统的业务逻辑的时候有以下特征：

1、与框架分离：系统架构不依赖于某个功能丰富的框架中的某个函数，框架被当作工具使用，不需要让让系统来适应框架。

2、可测试性：系统的业务逻辑可以脱离UI、数据库、Web服务及其他外部元素来测试。

3、与UI分离：UI必须能非常容易独立地修改。而不能在改变UI的同时需要改变系统其他部分。比如当把系统的UI从Web UI改成控制台UI，你并不需要改变任何业务逻辑的代码。

4、与数据库分离：能很方便地在Oracle，SQL Server，Mongo DB，BigTable，CouchDB或者其他数据库中进行切换和改变。业务逻辑决不能依赖这些数据库。

5、与外部结构分离：系统的业务逻辑并不需要知道任何外部的结构。

 

13.SOLID设计原则

SRP（单一职责原则）：每个软件模块都有且只有一个需要改变的理由。

适用范围：方法、类、接口、包、模块、应用(应用的职责)、系统(业务系统的边界)

OCP（开闭原则）：易于扩展、 修改关闭

LSP（里氏替换原则）：如果想用可替换组件来构建软件系统，那么这些组件必须遵守同一个约定，以便让这些组件可以相互替换。

ISP（接口隔离原则）：主要告诫软件设计师应该在设计中避免不必要的依赖。任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦

DIP（依赖反转原则）：依赖关系应该应该多引用抽象类型，而非具体实现

 

 

14.哪些类组合成组件

主要是解决组件聚合的问题

原则：复用/发布等同原则、共同闭包原则、共同复用原则。

 

15.管理依赖关系

主要是解决组件耦合的问题

帮助我们确定组件之间的相互依赖关系，要考虑三个原则：无依赖环原则、稳定依赖原则、稳定抽象原则。

ADP：组件依赖关系图中不应该出现环

SDP：依赖关系必须指向更稳定的方向

SAP：一个组件的抽象化程度应该与其稳定性保持一致。