| 边界手段 | 模块 API、包结构约束、构建期依赖检查 |
|---|---|
| 数据 | 单库但按模块划分 schema 或表所有权 |
| 价值 | 后续可平滑演进为服务化 |
- 按子域划分模块，以业务能力命名，不按技术分层
- 显式接口：模块只暴露 API 包，内部实现包禁止外部引用
- 构建期约束：接入依赖检查工具，违规引用直接失败
- 数据所有权：表归属单一模块，跨模块取数走接口
- 接口兼容：模块 API 变更走扩展-收缩，避免同步改多处
- 演进路径：边界稳定后优先拆分读多写少、团队独立的模块
依赖检查工具示例
| 技术栈 | 工具 |
|---|---|
| Java | ArchUnit |
| Python | import-linter |
| C# / .NET | NetArchTest |
| JS / TS | dependency-cruiser |
模块化单体的验收标准是“能否在不改动其他模块的前提下替换某个模块实现”。