夜雨聆风
分层插件化架构与五步设计法则
导读
很多工程师无法从高级开发进阶到架构师，是因为缺乏治理复杂度的结构化思维。
本专栏要介绍的两个实战项目，虽然业务迥异，但在底层架构上却遵循着同一个范式——分层插件化。这套架构风格是目前解决“核心稳态”与“业务多变”矛盾的最优解。
本文拆解这套架构的运作机制，并给出一套从需求到文档的五步架构设计流程。
分层
分层是软件工程的经典思想，本质是关注点分离，核心思想是，将一个复杂的问题分解成多个更小、更简单、更容易管理的问题，然后独立解决这些小问题。
在软件中，就是将不同的职责和功能划分开，让每一部分的代码都只关心自己的工作。
在一个前端项目中，典型的分层可能如下：
-
表现层：用户直接交互的UI界面。例如，由React/Vue组件、CSS样式、页面布局等构成。 -
业务逻辑层：处理应用的业务逻辑。例如，表单校验、特定领域的业务规则等。 -
数据层：负责数据的获取、格式化、缓存和同步。例如，API请求、数据适配、数据建模等。 -
基础设施层：提供整个应用通用的基础能力。例如，鉴权、国际化(i18n)、日志、通用工具函数库、UI组件库等。
软件分层的关键在于，识别变化频率的差异，并在此基础上建立清晰的契约。
架构师的核心工作之一就是设计出一个足够稳定、通用、有前瞻性的基础设施层和数据层，将其放在单独的仓库或一个大的代码仓库(Monorepo)中的独立包里中，这是实现隔离的有效手段，能有效降低开发者的认知负担。
识别出分层之后，还需要设计契约，让不同层能相互沟通，对于前端来说，约定通常是：
-
TypeScript 类型定义：精确函数签名、数据结构。 -
NPM 包：将基础设施层和数据层打包成 NPM 包，上层业务开发者像使用第三方库一样使用它。
插件化
插件化的核心是“自治”与“生命周期管理”。
自治，即，每个插件对应一个清晰的业务领域，由一个专门的团队全权负责。这个团队可以决定插件的技术选型、开发流程和发布计划。
生命周期管理，即，为系统中的插件群体提供从初始化到销毁的全过程管理。每个插件都拥有自己独立的生命周期，一个插件从立项、开发、上线、迭代完全不影响其他插件。
分层 + 插件化从两个垂直的维度，解构了一个复杂的系统：
-
分层是纵向切分，它按照技术关注点将系统从上到下切开（UI → 业务逻辑 → 数据 → 基础）。 -
插件化是横向切分，它按照业务领域将系统从左到右切开（业务A | 业务B | 业务C）。插件的切分只涉及 UI 和业务逻辑。
前端架构设计步骤
01.理解需求与目标
明确需求是架构设计的基石。如果目标模糊，后续的结构设计便无从谈起。
整个过程始于梳理系统的功能性需求，也就是明确系统需要为用户提供哪些具体功能，例如是否支持用户登录、内容发布、在线评论等。
然而，决定架构选型的，往往是那些隐藏在功能之下的非功能性需求，它定义了系统的质量属性，例如：性能、可伸缩性、可用性、可维护性、安全性以及成本控制。
这一阶段的关键产出是一份清晰的需求文档，其中量化了的非功能性需求列表尤为重要，它将直接指导后续的技术决策。
02.识别关键驱动因素与约束
需求繁多，但并非同等重要，这一步的工作是，从功能清单中，识别出对架构有决定性影响的驱动因素与无法逾越的约束条件。
具体做法是，从上一步的需求中，找出最重要的 2-3 个非功能性需求，这就是驱动因素。
比如，对于一个视频直播应用，低延迟和高并发至关重要；而对于一个银行内部系统，安全与数据一致性则高于一切。
与此同时，我们还必须明确那些无法改变的客观边界，即约束条件。这通常包括技术栈限制、团队技能水平、项目交付时限以及相关的法律法规等。
经过这番权衡，便得到了一份排好优先级的架构目标和一份明确的约束清单。
03.系统设计
在明确了驱动因素与约束后，我们便可以开始自顶向下的架构设计。
-
选择架构风格：首先，根据核心驱动因素选择一个合适的架构风格。例如，若首要考虑的是职责分离和可维护性，分层架构便是一个理想的选择。 -
定义分层与职责：接着，需要明确定义应用具体包含哪几层（如表现层、应用层、领域层、数据层），并用一句话精准概括每层的核心职责。这能确保团队对架构有统一的认知，从根本上避免未来出现代码归属不清、跨层调用混乱的问题。 -
模块设计与接口契约：最后，深入到每个分层内部进行详细设计。这包括划定模块边界，明确每个模块做什么与不做什么，以防止功能蔓延和职责模糊，还要设计交互 API，定义模块间通信的接口，确保协作的稳定性与规范性。
这一系列设计工作的最终产出物应包含系统架构图、模块关系图、核心数据模型以及接口（API）规范，用以清晰地展示层与层、模块与模块之间的静态关系和动态数据流。
04.技术选型
在成熟的公司中，我们往往在既有技术栈上做增量调整，鲜有机会从零开始进行完整的技术选型。但理解完整的选型流程至关重要。
对每一层分别进行技术选型，首先要响应前序步骤中明确的需求清单、关键驱动因素和约束条件。在此基础上，还需纳入两个宏观层面的考量：
-
人才市场状况：它直接决定了项目的人力成本、招聘难度和长期维护的稳定性。 -
技术趋势与生命周期：我们应选择处于上升期、社区活跃的技术，避免采用已停滞或日渐式微的方案。这能确保技术栈在未来数年内保持生命力，避免因过时而引发大规模重构。
最终，我们需要产出一份详尽的技术栈清单。但清单本身并非关键，清单背后针对每一项选择的理由，才是技术选型工作的核心价值所在。
05.文档化与评审
将前述所有的思考与权衡，系统性地沉淀为一份清晰的架构文档。这其中，至关重要的是，为每个关键决策建立架构决策记录，详细记述做出某项决策时的背景、方案评估、最终选择的理由以及预期的后果，这对于未来的维护至关重要。
文档完成后，组织一次正式的架构评审会也必不可少。邀请开发、产品、测试、运维等各方利益相关者参与，向他们清晰地阐述设计方案，并收集反馈。这个过程可能会涌现出许多质疑和建议，这是在早期阶段发现潜在问题、达成共识的关键一步。
总结
你可能背熟了这五个步骤，但当面对老板一句模糊的“我们要搞个低代码平台”时，第一步该如何迈出？如何从杂乱的业务描述中提炼出关键约束？
下一步正式进入实战。以低代码引擎为例，模拟架构师的工作场景。
