📚 课程目录第1章模块间通信的宏观定位

1. 模块间通信的宏观定位：架构分层、通信域划分、解耦原则

1.1 章节定位与核心命题

模块间通信并非单纯的“接口定义”或“RPC选型”，而是架构落地中最直接反映系统边界稳定性与耦合度的关键决策层。本章作为讲义的开篇，旨在建立统一的宏观坐标系：为什么通信设计必须基于分层架构？通信域如何划分？解耦原则如何贯穿始终？

架构师视角： 任何两个模块之间的通信，都隐含着三个维度的决策——数据所有权（谁负责数据的正确性）、控制权（谁触发流程）、信任边界（是否需要验证、限流、重试）。本章回答的是“如何在一开始就划定这些边界”。

1.2 架构分层：通信设计的第一约束

没有分层，就没有稳定的通信接口。分层架构将一个横跨多层的“大泥球”拆解为具有明确职责的层次，每一层对上层暴露服务，对下层依赖抽象。这种结构直接决定了通信的走向与协议选择。

分层维度	典型层级	通信意图	常见协议/模式
技术分层	接入层 → 业务层 → 基础层	请求-响应、异步通知	HTTP/gRPC、消息队列
领域分层	用户界面 → 应用服务 → 领域层 → 基础设施层	命令、查询、事件	领域事件、CQRS、仓储接口
部署分层	客户端 → 网关 → 微服务 → 数据层	南北向流量、东西向流量	API Gateway、服务网格、数据库驱动

分层的关键风险：层间泄漏。表现为下层数据结构向上穿透、上层业务逻辑下沉至通信层。落地方案中，应当为每一层定义严格的通信白名单：允许哪些模块调用哪些模块、通过什么协议、传输什么结构的数据。

1.3 通信域划分：内部域、边界域、外部域

在分层基础上，还需按信任与归属关系划分通信域。每个域内的通信策略截然不同：

内部域（Intra-Domain）：同一模块内部或同一子系统的子模块之间。通信以函数调用、进程内事件驱动力主，追求极低延迟与强一致性。
边界域（Boundary Domain）：不同模块/服务之间的通信。必须定义版本化的 API 契约，采用异步化、限流、熔断等手段管理故障隔离。
外部域（External Domain）：与系统外部的第三方、客户端、遗留系统的通信。需引入认证、授权、审计、协议适配层。

易犯错误： 将外部域的错误处理策略（如全局重试、强认证）直接照搬到内部域，导致轻量级模块间通信变得臃肿；或者将内部域的乐观假设直接暴露给外部，引发安全漏洞。

1.4 解耦原则：通信设计的灵魂

模块间通信的全部努力，最终都指向降低耦合。具体原则可归纳为三条：

契约优先原则：通信双方不依赖对方的实现，只依赖共同约定的接口契约（Schema、IDL、事件形状）。

// 错误的通信：A 直接读取 B 的内部数据结构
// 正确的通信：A 消费 B 发布的 "OrderPlaced" 事件，事件结构由独立的事件库定义

数据所有权原则：通信中传输的数据，只能由拥有该数据的服务修改版本或形状。

# 反模式：ServiceA 传递 JSON 中包含 ServiceB 的内部状态字段
# 正常模式：ServiceA 只传递 OrderId，ServiceB 自己查询状态

信任边界最小化原则：跨域通信必须做输入校验、限流、trace；同域通信可以省略部分安全开销，但仍保留健康检查与超时。

1.5 宏观架构图：分层、域与解耦的关系

下图展示了单一系统中三个通信域如何在分层架构中分布，以及解耦原则如何作用于边界。

图中按外部域、边界域、内部域划分三层架构（接入层、业务层、基础层），左侧为外部通信域（需认证、协议转换），中间为边界域（采用契约化接口、异步消息、受控重试），右侧为内部域（直接函数调用、共享事件总线）。箭头表示数据流/控制流方向，虚线箭头代表跨层依赖关系。

1.6 落地步骤与验收标准

从宏观定位到实际操作，可按以下步骤推进：

步骤一：梳理系统分层地图 — 明确技术分层 vs 领域分层的对应关系，画出每个模块归属的域。
步骤二：定义每个通信域的“信任级别” — 外部域为T1（低信任），边界域为T2（中等信任），内部域为T3（高信任）。
步骤三：为每个域选择通信协议与模式 — 外部域必须用 HTTPS + OAuth；边界域优先异步消息或 gRPC；内部域非强制但建议事件驱散。
步骤四：编写通信契约（IDL/Schema） — 边界域接口必须通过版本化 schema 控制，不依赖任意实现细节。
步骤五：设计跨域通信的失败处理策略 — 超时、重试、降级、熔断、死信队列。

验收项	验收标准	检查方法
分层合规性	不存在下层接口透传至上层调用方；跨层调用必须通过抽象接口	代码审查 + 依赖关系图扫描
通信域划分清晰	每个通信接口明确标注所属域；域间通信协议与域内通信协议不混用	API 清单标注 + 架构评审
解耦原则落地	所有跨域接口均定义独立版本号；单一方无法修改接口而不通知另一方	契约兼容性测试 + 变更通知日志

1.7 关键风险点与权衡

风险： 过早的分层精细化和域划分会导致“过度设计”，增加初始开发成本。权衡在于：前两次迭代保持 2~3 层大颗粒度分层，随业务复杂度增加再逐步拆解域。不要一开始就为所有内部模块定义跨域接口。

另一个常见风险是通信域信任级别与实际情况不匹配：例如将内部模块的进程内调用误判为域间通信而加入大量序列化/反序列化开销，或将外部接口的认证策略复制到内部服务间调用而导致性能瓶颈。建议在架构文档中显式标注每个接口的trust_level与overhead_budget（单位毫秒），作为选型与重构的依据。

架构师 Checklist：

□ 是否已画出分层与通信域的 2x2 矩阵图？

□ 每个接口都标记了协议、域归属、信任级别？

□ 是否有一致的契约命名规范（如 com.company.modulename.v1）？

□ 团队成员是否理解“内部域不走 HTTP，外部域不走共享内存”等约定？

本章为后续所有通信细节（协议选型、序列化、错误处理、版本演进）建立了统一的坐标系。在进入具体技术决策前，务必确保团队对分层、域、解耦原则达成一致共识。