flowchart LR
N0["01 职责与分层"]
N1["02 按业务分模块"]
N2["03 模块边界验证"]
N3["04 事务与事件"]
N4["05 幂等与恢复"]
N5["06 服务拆分判断"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
应用架构与模块化单体
现代 Java Backend Engineering 学习路线：应用架构与模块化单体
0 子目录5 文档
CHAPTER OVERVIEW · 章节概览
先在一个应用中把模块边界守住，再处理事务与事件；只有证据表明需要独立服务时，才讨论拆分。
本章学习路线
箭头表示建议的学习顺序；先理解问题，再逐步进入实现与实践。
按顺序学习
5应用架构与模块化单体：先学会维护一个单体当订单逻辑散落在很多包里，改一个字段都要搜索半个项目时，就该重新考虑代码如何组织。模块化首先是让相关业务待在一起，并限制互相访问的方式；它不要求你立刻拆服务。Layered、Package by Feature 与领域边界按 Controller、Service、Repository 分包容易上手，但项目变大后，同一个业务可能分散得很远。下面比较按功能组织代码的方式，并说明模块内部仍然可以分层。重点是让一次业务改动有清楚的范围。Spring Modulith：模块验证、集成测试、事件与可观测性约定“订单模块不要直接访问库存内部类”很容易，长期遵守却需要工具帮助。Spring Modulith 可以检查部分模块关系，并支持围绕模块测试和观察事件。它验证的是你的设计，不会自动替你划分业务。Transaction Boundary、Outbox 与 Idempotency保存订单成功后，发送消息失败了怎么办？数据库与消息系统之间的这个间隙，是 Outbox 要处理的问题。下面先看业务记录与待发消息怎样一起保存，再解释为什么后续发送和消费仍然需要处理重复。模块化单体到微服务：什么时候应该拆？拆成多个服务后，每个服务可以独立发布，但本地调用也变成了可能超时的网络调用。先看独立扩容、团队协作或隔离需求是否真实存在，再决定是否拆分；仅仅目录多、代码多，并不足以支持这个决定。