2. 多租户业务流程需求设计方法论

2.1 概述：从业务混沌到结构化需求

多租户 SaaS 的业务流程设计面临一个根本矛盾：租户业务千差万别，而平台必须提供统一、可配置、可扩展的需求基线。传统单租户的“访谈→文档→开发”模式无法承载多租户场景下的边界模糊、角色冲突、数据流交织等问题。

本章提出的四步方法论——事件风暴、角色矩阵、服务蓝图、需求优先级排序——构成一条从业务混沌到结构化需求的可复现路径。每一方法解决一个核心维度：

2.2 事件风暴：识别租户边界与聚合

事件风暴（Event Storming）是Alberto Brandolini提出的协作建模技术，核心是在时间轴上排列业务事件，识别引发事件的命令、聚合、限界上下文。在多租户SaaS中，事件风暴承担两项关键职责：

• 租户业务事件归一化： 将不同租户看似不同的业务操作抽象为统一事件（如“订单已创建”“发票已生成”），消除表达差异。
• 聚合边界判定： 明确哪些事件属于同一个聚合（Aggregate），聚合边界直接决定后续的数据隔离粒度——是按租户分库、按聚合分表，还是混合策略。

边界识别要点

• 租户无关事件 vs. 租户敏感事件： 系统事件（如“定时任务触发”）与租户业务事件（如“租户A的订单已支付”）必须分离，前者走全局通道，后者走租户上下文。
• 聚合的租户归属： 每个聚合实例只能属于一个租户，聚合根ID中必须携带租户标识（tenant_id）或通过路由表映射。

2.3 角色矩阵：定义租户角色与权限分层

角色矩阵（Role Matrix）将事件风暴中识别出的“执行命令的角色”与租户层级结合，形成二维权限网格。多租户SaaS通常包含三个角色层级：

1. 平台层角色： 超管、运维、审计——管理租户生命周期、全局配置、资源配额。
2. 租户管理层角色： 租户管理员、部门主管——管理本租户内的用户、权限和业务配置。
3. 租户业务层角色： 普通员工、外部访客——执行业务操作，数据范围限定在租户内。

矩阵的每一行是角色，每一列是资源/操作，交叉点标记“允许/拒绝/条件允许”。条件允许是多租户特有的——例如“允许查看本部门订单，但不可查看跨部门订单”。

数据隔离策略的输入来源

角色矩阵直接决定数据查询时的过滤条件：

-- 角色矩阵输出示例：租户管理员查询订单
SELECT * FROM orders
WHERE tenant_id = :current_tenant_id   -- 租户隔离
  AND (dept_id = :user_dept_id OR :is_admin = true);  -- 角色条件

2.4 服务蓝图：设计服务交互与数据流

服务蓝图（Service Blueprint）将事件风暴中的业务事件和角色矩阵中的角色映射为具体的服务交互流程。蓝图包含三条核心链路：

• 控制流（Control Flow）： 请求如何从客户端经API网关、认证中心、路由层到达业务服务，每次跳转的租户上下文传递方式（JWT中的tenant_id、请求头X-Tenant-ID）。
• 数据流（Data Flow）： 服务读写数据时如何命中正确的租户分片，跨租户聚合查询的边界在哪里，共享数据（如全局字典）与隔离数据（如业务单据）如何区分。
• 信任链路（Trust Chain）： 从客户端到服务端的身份断言链，确保租户身份在每一步都被校验且不可篡改。

组件职责与分层

2.5 需求优先级排序：权衡选型与风险排序

在资源有限的情况下，必须对事件风暴、角色矩阵、服务蓝图中产出的需求进行优先级排序。排序标准围绕多租户特有风险展开：

1. 数据隔离风险等级： 涉及租户数据泄露的需求（如跨租户报表、共享缓存）优先级最高，须在MVP中解决。
2. 配置复杂度影响面： 影响所有租户的配置变更（如新增字段、修改验证规则）比单租户定制优先级更高。
3. 租户增长瓶颈： 限制新租户接入的需求（如租户注册流程、套餐分配）排在最前。
4. 运维可观测性： 租户级别的日志、监控、配额告警在规模化前必须就位。

2.6 四者协同关系

四个方法论构成一个迭代反馈环：事件风暴输出的聚合边界为角色矩阵提供权限作用域；角色矩阵的角色分层影响服务蓝图中的过滤逻辑；服务蓝图中的接触点暴露新的业务事件，修正事件风暴模型；需求优先级排序的取舍结果反馈至事件风暴，调整下一次迭代的广度。下图展示这一协同框架：

下表从输入、输出、核心产出物、数据隔离关联四个维度对比四个方法论：

2.7 落地步骤

在真实项目中，建议按照以下五步迭代推进：

1. Step 1 · 全景事件风暴（2～3轮）：
   • 邀请业务方、运营方、开发方共同参与，在时间轴上贴出所有业务事件。
   • 标记出“租户触发的命令”与“系统触发的命令”，用颜色区分。
   • 产出：聚合边界草稿 + 事件目录。
2. Step 2 · 角色矩阵构建（1～2轮）：
   • 从事件风暴中提取所有“执行者”，按平台层/租户管理层/租户业务层归类。
   • 对每个角色，列出可访问的聚合与操作类型（CRUD）。
   • 产出：角色-权限矩阵表 + 数据可见性规则。
3. Step 3 · 服务蓝图绘制（2轮）：
   • 针对每个核心业务事件，画出从客户端到数据层的完整请求路径。
   • 在每个跳转点标注租户上下文传递方式与校验逻辑。
   • 产出：服务交互蓝图 + 数据流示意图。
4. Step 4 · 需求优先级排序（1轮评审）：
   • 将前三步产出的所有需求条目放入“风险-价值”四象限。
   • 识别出必须在前置阶段解决的“硬依赖”需求（如租户路由基础组件）。
   • 产出：优先级排序清单 + MVP范围定义文档。
5. Step 5 · 迭代收敛（持续）：
   • 每个交付周期结束后，回到事件风暴重新审视未覆盖的事件或边界变化。
   • 将运维阶段发现的“缺失事件”或“权限漏洞”补充进下一轮方法论循环。

2.8 验收标准

本章方法论的应用效果可通过以下标准检验：