中型业务模块整合的关键在于职责边界清晰、通信可控、演进可预期；需通过API模块定义稳定接口、契约先行、轻量通信、事件驱动最终一致性及组装层专注编排来实现。
中型业务模块整合的关键不在代码量，而在职责边界清晰、通信可控、演进可预期。Java生态提供了足够成熟的工具链，但真正决定整合质量的是设计意识——不是“能不能连上”，而是“该不该这样连”。
明确模块边界与契约先行
模块不是按功能切分的包，而是具备独立生命周期、可验证行为的协作单元。每个模块对外只暴露接口（Interface），不暴露实现类；接口定义在独立的API模块中，供其他模块依赖。
- 用Maven多模块结构：common-api（纯接口+DTO）、module-a、module-b、application（组装层）
- 接口方法签名要稳定：避免返回List
- 版本管理：API模块发布时打语义化版本（如1.2.0），消费者通过
[1.2.0, 2.0.0)
模块间通信走轻量协议，不直调实例
禁止跨模块new对象或@Autowired注入对方ServiceImpl。通信方式按场景分级选择：
- 同JVM内高频调用：用Spring Cloud OpenFeign（声明式HTTP）或Dubbo泛化调用，走本地代理，保留超时、重试、降级能力
- 异步解耦：核心流程发事件（Spring ApplicationEvent + ApplicationRunner初始化监听器），非核心动作订阅处理（如日志归档、通知推送）
- 跨服务边界：强制走REST或gRPC，DTO序列化前做显式校验（@Valid），错误统一包装为Result
结构，含code、message、traceId
状态协同靠事件溯源+最终一致性
中型系统很少需要强一致性事务。模块A修改自身状态后，发领域事件（如OrderPaidEvent），模块B监听并更新本地视图。关键在补偿与可观测：
立即学习“Java免费学习笔记（深入）”；
- 事件必须持久化落库（如event_store表），再发MQ，防止丢失；消费端做幂等（用event_id+业务唯一键联合去重）
- 关键链路埋点：每个事件处理记录start_time、end_time、status、error_stack（如有），接入ELK或SkyWalking
- 对账机制：每日定时比对核心单据（如订单/支付/库存）在各模块中的状态，差异自动告警并生成修复工单
组装层专注编排，不掺杂业务逻辑
application模块是“胶水”，只负责调用顺序、参数转换、异常映射，所有判断和计算下沉到对应模块内部：
- 一个下单接口的编排示例：
→ 校验用户权限（调user-api）
→ 锁定库存（调inventory-api，返回lockId）
→ 创建订单（调order-api，传入lockId）
→ 支付跳转（返回payUrl）
不做“如果库存不足则推荐替代商品”这类逻辑——那是inventory-module的职责 - 用CQRS分离读写：写操作走领域服务，读场景直接查聚合查询库（如Elasticsearch或宽表），不拼JOIN
不复杂但容易忽略。模块整合不是堆技术，而是用约束换自由——划清边界，才能放心迭代。
