为什么要将业务与基础设施分开?
答:引起它们变化的原因不同 单一职能原则的体现
经典分层架构
最为经典的就是三层架构以及领域驱动设计提出的四层架构。
经典三层架构:
用户界面层(User Interface Layer)、业务逻辑层(Business Logic Layer)与数据访问层(Data Access Layer) 如下图所示:
流行原因:
系统复杂度低
优点:
隔离了 业务逻辑 与数据访问逻辑 使 业务逻辑 与 数据访问逻辑 可以自由 并 独立地演化
领域驱动设计的经典分层架构:
在经典三层架构的基础上做了进一步改良:
在用户界面层与业务逻辑层之间引入了新的一层,即应用层(Application Layer):
数据访问层更名为基础设施层
各层的职责:
层次 | 职责 |
---|---|
用户界面/展现层 | 负责向用户展现信息以及解释用户命令 |
应用层 | 很薄的一层,用来协调应用的活动,它不包含业务逻辑,它不保留业务对象的状态,但它保有应用任务的进度状态 |
领域层 | 本层包含关于领域的信息,这是业务软件的核心所在。在这里保留业务对象的状态,对业务对象和它们状态的持久化被委托给了基础设施层 |
基础设施层 | 本层作为其他层的支撑库存在。它提供了层间的通信,实现对业务对象的持久化,包含对用户界面层的支撑库等作用 |
分层架构的本源
分层架构适用工程:
能被分解成子任务组,其中每个子任务组处于一个特定的抽象层次上。
分层的依据与原则:
分层的第一个依据是:基于关注点为不同的调用目的划分层次
分层的第二个依据是:面对变化
层与层之间的关系:应该是正交的,所谓“正交”,并非二者之间没有关系,而是垂直相交的两条直线,唯一相关的依赖点是这两条直线的相交点,即两层之间的协作点
非正交,即“斜交”,当一条直线延伸时,它总是会投影到另一条直线,这就意味着另一条直线会受到它变化的影响。
层与层之间的协作
抽象不应该依赖于细节,细节应该依赖于抽象。
“针对接口编程,而不是针对实现编程”。高层模块对低层模块的实现是一无所知的,带来的好处是:
-
低层模块的细节实现可以独立变化,避免变化对高层模块产生污染
-
在编译时,高层模块可以独立于低层模块单独存在
-
对于高层模块而言,低层模块的实现是可替换的
识到层次多少的利弊:过多的层会引入太多的间接而增加不必要的开支,层太少又可能导致关注点不够分离,导致系统的结构不合理。