「这是我参与2022首次更文挑战的第29天，活动详情查看：2022首次更文挑战」

分层架构

开发程序时,大部分开发者都没有正式整理良好的架构, 一般会采用标准且传统的分层架构,也叫n层架构. 通过源码模块所在的包进行分层.这种没有组织的源代码模块, 缺少了明确的角色,功能和其他模块之间的关系, 这种常称为反模式的泥球架构.

对于没有架构的程序,常有几下几问:

架构模式用于定义程序的基本特征和行为. 有的架构可伸缩性好,有的灵活,了解架构的特征/优势/弱点, 才能在具体场景中做出正确的选择. 架构师需要时刻证明架构决策的正确性.

最常用的架构模式是分层,这种架构模式最贴近传统的it交流和公司的组织结构,所以是商用程序开发者的首选.

分层模式解释

每一层表示程序的一个特殊角色,每一层会有多个组件.

分层模式并未指明有多少层,大多数分层架构分4层:

这是典型的j2ee程序的分层,有时业务和持久化都会归为业务层, 尤其是sql硬编码到业务层时.

每层都有一个特殊的角色: 呈现层负责和用户交互,浏览器交互;业务层负责处理请求.

每个角色(每层)都围绕某个任务的抽象表示,呈现层不处理数据, 业务层不管如何显示.

分层模式最大的优点是通过组件隔离. 每个组件只处理与该层相关的逻辑.

分层架构第一个核心概念是closed,每层都可标记为closed, closed层意味着请求可以传递到下一层,不能跨层. eg:呈现层不能直接访问数据库层.这是为了隔离.

经凑型程序(未分层)会丢失组件之间的相互依赖, 这类架构的变更会变得非常困难且代价昂贵.

层的隔离概念是第二个概念,意味层只能影响相邻的层, 同时意味层和层是独立的,说白点就是这层不知道其他层的内部细节, 也无需知道.这个特点非常强大和重要. eg:重构呈现层,业务层压根不需要动. 好处就是:只要层和层之间的接口约定不变,层内部可任意重构和变更.

有的层是open的,表示上面的层可以越过当前层直接访问下一层. 层的closed和open用于定义层和层的关系,也是请求的流向, 也是便于架构师和开发者理解架构.

分层模式是通用模式,如果不确定用什么模式,就用分层模式.

选择分层模式就需要考虑以下几点:

各模式之前的比较可看附录

整体灵活性

低,分层结构整体还是紧凑的,对整体的修改会耗时耗力.

部署难度

高,对大型程序,部署难度取决于分层架构是如何实现的; 一个组件的小改动可能需要整个重新部署.

可测试性

高,每个组件都可测试,mock/stub.

性能

低,分层架构的目的不是高性能,一个请求会过多个层.

可伸缩性

低,分层架构趋向高耦合和整体实现,很难伸缩. 可单独将某层分割,进行单独的物理部署,总的来说很难.

开发难度

低,实现不复杂,很多公司的组织结构天生贴合分层结构.