这是海哥的第 94 篇原创

前言

在基于易变性完成系统整体拆解之后，架构设计正式进入结构落地阶段。合理的架构分层、标准化的服务分类、统一的组件命名规范，是把抽象架构思想转化为可落地、可协作、可迭代软件系统的核心支撑。统一且清晰的组件命名体系与组件关系定义，能够为架构设计带来两大核心价值：

1. 为整体架构搭建提供标准化设计起点，规避设计思路散乱无章的问题；
2. 打通团队沟通壁垒，让架构师、开发人员、运维人员快速读懂设计意图，梳理自身设计逻辑，高效传递设计思想。

架构结构设计不再局限于单纯的模块划分，而是围绕服务语义、易变性隔离、分层准则搭建基础设计体系，从需求梳理、层级划分、服务归类完成基础架构搭建，彻底摆脱功能拆分带来的架构臃肿、耦合过高、迭代困难等各类问题。

第一章需求与用例：摒弃功能定义，聚焦行为本质

1.1 需求收集核心原则

软件需求编写与收集，核心要义是捕获系统所需行为，而非罗列系统所需功能。

传统需求习惯于定义系统 “需要做什么”，固化功能拆分思维，无法适配业务动态变更。 标准化需求设计，应当明确界定系统如何交互运行，梳理内外部完整交互链路、执行逻辑、响应规则，这才是需求收集的核心本质。

行为化需求梳理工作量更大，也是多数团队刻意回避的环节，但却是搭建高韧性架构的必备基础。

1.2 用例：业务价值行为的具象表达

用例是系统所需行为最直观的表达形式，定义系统完成业务动作、创造业务价值的完整活动序列。 覆盖范围：

• 终端用户与系统前端交互
• 系统与第三方外部系统对接
• 后台自动化后端处理流程

纯文字用例弊端：信息接收主观、阅读效率低、易产生理解偏差。

最优方案：采用图形化、图表化方式表达，人脑接收可视化信息效率更高；缺点是标准图形用例绘制耗时较高。

1.3 核心视图选型

1.3.1 用例图

以使用者为核心，仅梳理用户与业务场景对应关系，无时间、无执行序列、无先后流程，多用于整体业务边界划分。

示意图参考：

系统用户 ------> 账户查询系统用户 ------> 账户转账管理员   ------> 账务对账

特点：结构简洁、业务边界清晰，仅展示谁能做什么，不展示执行流程。

1.3.2 活动图

元设计方法主推用例可视化载体，优势远超普通流程图：

• 支持并行执行、流程阻塞、事件等待
• 原生具备并发性能力
• 精准捕获业务行为关键时间节点

普通流程图无法实现复杂时序与并发逻辑表达。

总结：复杂核心业务优先使用活动图，基础业务场景使用用例图即可平衡成本与效率。

第二章 软件系统分层设计体系

分层架构是通用软件设计模式，元设计方法同样以分层为核心骨架。分层核心思想：每一层独立封装上下游易变性，同层服务完成局部易变性隔离，所有分层最终以物理资源层收尾。

跨层级交互优先选用服务调用，再根据业务场景选定技术栈与运行平台。 服务调用六大核心优势： 可扩展性、安全性、吞吐量与可用性、可靠性、业务一致性、业务同步适配能力。

2.1 五大标准分层架构

2.1.1 客户端层

传统表示层定义存在误导，客户端层交互主体包含人类用户 + 外部系统。

设计特点：

1. 统一系统访问入口，统一安全规则、数据格式、接口规范，提升复用性与可维护性；
2. 客户端是系统易变性最高层级：技术栈不同、部署方式不同、版本周期不同、开发团队不同；
3. 层内完成易变性完整封装，单一客户端修改不会影响其他客户端。

2.1.2 业务逻辑层

系统核心中枢，封装全部业务逻辑易变性。

用例两大变更形式：

1. 业务活动执行序列发生变更
2. 用例内部具体活动逻辑发生变更

拆分两类专用组件隔离变更：

• 管理器 Manager：封装业务序列易变性，聚合逻辑相近业务用例，独立承载子系统工作流；
• 引擎 Engine：封装业务活动易变性，承载固定业务规则、核心运算与标准化执行动作。

交互原则：多个管理器可共用同一引擎；同一活动被不同管理器调用不同引擎，属于功能拆分误区。

2.1.3 资源访问层

统一封装资源访问方式易变性与资源本身形态易变性，层内组件统称为资源访问组件。覆盖变更场景：

• 数据库访问方式迭代调整
• 本地存储 ↔ 云存储切换
• 内存存储 ↔ 持久化存储切换

核心设计规范

1. 使用原子业务动词 从业务视角定义不可拆分操作，底层技术步骤对内隐藏。银行转账经典案例： 业务层面：转账 为原子业务操作 底层实现：拆分 借记账户、贷记账户两步操作 架构设计要求：上层业务只调用转账原子动作，底层逻辑由资源访问层内部实现。
2. 隐藏资源类型，拒绝暴露底层实现 禁止接口命名出现 Select/Insert/Delete（数据库特征）、Open/Read/Seek（文件特征）。 优质组件仅对外暴露业务层面原子操作。
3. 高复用性设计 资源访问服务可被管理器、引擎全局共享；无法共用则代表易变性未合理隔离。

2.1.4 资源层

架构最底层物理承载层，存放系统依赖实体资源： 数据库、文件系统、缓存、消息队列、第三方外部服务等。 资源不分内外，外部独立系统在本架构中仅作为底层资源接入。

2.1.5 实用工具栏服务

独立于业务分层之外，横向贯穿所有架构层级，属于系统通用基础设施。 常见工具服务： 安全校验、日志记录、故障诊断、运行监控、发布订阅、消息总线、托管服务等。 工具服务拥有独立设计准则，与业务服务严格区分。

2.2 层级易变性 & 复用性精简对比

第三章 架构服务分类与标准化命名指南

3.1 服务命名统一规范

统一命名是团队架构沟通、落地协作的基础，适用于业务层、资源访问层。

1. 命名结构：双部分复合词 + 驼峰命名
2. 固定后缀：Manager 管理器、Engine 引擎、Access 资源访问
3. 前缀规则 

• 管理器前缀：关联用例易变性的名词
• 引擎前缀：描述封装业务活动的名词
• 资源访问前缀：关联业务资源与业务数据的名词

1. 动名词限制：仅引擎可使用动名词前缀，其余层级使用即代表功能拆分
2. 用词边界：原子业务动词仅用于资源访问层接口，不用于服务名称前缀

3.2 银行转账业务命名正误对照表

命名详细解读

1. AccountManager 账户管理器 聚焦账户整套业务流程序列，封装查询、转账、冻结等流程顺序变更，贴合易变性封装思想。
2. SettlingEngine 清算引擎 专注资金清算、金额核算、合规校验等固定业务活动，可被多个账户管理器复用。
3. AccountAccess 账户资源访问 统一封装账户数据读写、多数据库适配、本地 / 云端存储切换，完全隐藏底层存储细节。

3.3 分层对应四大设计问题

可用于架构搭建思路梳理，也可用于设计完成后校验纠错：

• 谁 → 客户端层：确定所有交互主体
• 什么 → 业务管理器：梳理系统业务需求与用例
• 如何 → 引擎（业务执行方式）+ 资源访问层（资源调取方式）
• 在哪里 → 资源层：确定数据与系统状态存储位置

校验原则：出现层级职责交叉，重新优化易变性隔离方案。

3.4 管理器与引擎数量配比

• 2 个管理器 → 最优搭配 1 个引擎
• 3 个管理器 → 最优搭配 2 个引擎
• 5 个管理器 → 最多搭配 3 个引擎
• ≥8 个管理器 → 架构设计失效，多为过度功能拆分导致

优化思路：单个管理器可通过多组服务契约承载多类用例，精简组件数量。

3.5 分层架构三大核心规律

规律 1：易变性自上而下逐级递减

客户端 > 管理器 > 引擎 > 资源访问层 > 底层资源层

规律 2：重用性自上而下逐级递增

客户端几乎不可复用，底层物理资源全局复用性最强。

规律 3：管理器三类形态判定

1. 昂贵型管理器 变更抵触、改造成本高，根源：组件臃肿、功能拆分不合理
2. 消耗型管理器 随意调整、无设计逻辑，属于架构冗余产物
3. 近似可消耗型管理器（最优） 可快速适配业务序列变更，仅负责调度引擎与资源访问，纯粹封装序列易变性

文章小结

本文是软件架构分层设计指南上篇，完整梳理需求用例设计、五层标准架构体系、服务标准化命名三大核心基础内容。 全程围绕易变性隔离为核心，摒弃传统功能拆分设计思维，通过视图选型对比、层级特性表格、银行业务实战命名案例，快速落地架构基础设计规范。

下篇要讲解的内容是：子系统聚合、增量构建、可扩展性设计、三大架构范式、架构设计禁忌与对称设计原则。