使用 DDD 思想组织你的代码

核心目标

优先按业务能力、子系统、限界上下文组织代码，而不是把 models/、services/、repositories/、schemas/、api/ 这类技术类型目录平铺在项目根下。

目标不是机械套用 DDD 术语，而是让一个功能的核心代码尽量收敛在同一业务子系统内，做到高内聚、低耦合、边界清晰、易于协作和演进。

适用原则

在开始设计结构或新增模块前，先判断“这段代码属于哪个业务能力”，再决定目录位置。

始终优先回答这几个问题：

1. 这段代码服务于哪个业务子系统？
2. 这个子系统的核心职责是什么？
3. 它需要暴露什么公共接口给其他子系统？
4. 它依赖哪些共享能力，哪些依赖不应该直接发生？

如果一个需求横跨多个目录才能完成，优先怀疑目录组织方式有问题，而不是继续往现有的按类型结构里堆代码。