用途：在单一部署中按限界上下文划分模块，兼顾同一事务的便利与后续服务化拆分。适合一个或少数团队、单一流水线、领域尚不稳定或数据耦合频繁的场景；不应用它作为全局 common 目录的借口，也不是“带命名空间的混乱单体”。
主要能力：模块即上下文，例如 apps/api/modules 下放 catalog、ordering、billing，shared 仅保留最小内核（如 id、clock），不放领域。每个模块包含代码、schema（前缀表或独立 SQL schema）与测试。依赖只能走模块公开 API（如 orderingapi.PlaceOrder），禁止引用 internal 或邻居的 db 包，禁止循环依赖；若 A 与 B 互相需要，用事件、ACL，或说明边界划错。
数据：写操作由各模块拥有自己的表，不做跨模块外键（除非是稳定且有意为之的契约）；读其他上下文用属主 API/查询、物化视图或最终一致副本，不做全局 ORM 静默 JOIN。同库跨模块事务是需文档化的例外，首选最终一致。
垂直切片：模块内按功能而非全局分层组织，如 ordering/placeorder 下放 handler、service、sql；切片可访问本模块领域，不导入 billing 适配器；切片变大再引入 Clean 分层，不必为每个 POST 强上四层项目。
宿主：单一 main 注册模块、中间件与配置；认证在宿主，授权在资源属主模块；用特性开关隐藏未完成模块，避免散落的 if module == nil。
拆分：出现不同部署节奏、不同伸缩、独立团队或可隔离故障时再拆服务；检查公开 API 是否稳定、数据可否复制、事件是否已存在、契约是否已测。
反模式：shared/domain 放全部实体、一个被所有人使用的巨型 DbContext/PrismaClient、按层划分模块、首个 PR 就拆微服务、内部导入“只此一处”。
限制：资料未提供具体语言、框架、安装命令、收费或平台信息；示例路径与命名仅为示意。