在后端领域建模、依赖边界审查或架构重构时，用…

适用于聚合建模、限界上下文、用例隔离或架构重构，并指导或审查后端领域与依赖边界。

适用场景

解决思路

1. 用这些相关模式解决具体的领域或依赖问题；将其视为有观点的综合方案，而非强制目录布局；用户明确指示优先于本技能指南。
2. 从请求的行为、现有领域模型和当前依赖开始；除非改变语言和架构本身就是任务的一部分，否则保留项目现有语言与架构。
3. 简单 CRUD 可以保持简单；团队规模、实体数量、文件长度不能决定是否适合采用 DDD。
4. 按设计问题选择模式：业务语言与一致性规则用 DDD、限界上下文、聚合。
5. 按设计问题选择模式：源码依赖方向用 Clean/Onion Architecture。
6. 按设计问题选择模式：应用需要使用不同接口或基础设施时用 Hexagonal 端口与适配器。
7. 按设计问题选择模式：读写需要不同模型时用 CQRS。
8. 按设计问题选择模式：状态必须从事件历史重建时用 Event Sourcing。
9. 如果业务不变量未知，指出具体缺失的规则，并继续不依赖该规则的工作；不要编造业务行为，也不要为局部修复强制要求发现工作坊。
10. 保持领域行为独立于 HTTP、持久化和消息实现；把编排放在应用用例中，把外部 I/O 放在适配器中。
11. 将实体身份与值对象相等性分开建模；根据事务不变量和竞争情况选择聚合边界。
12. 优先让事务包含在单个聚合内；当需求需要跨聚合原子性时，明确说明该权衡，而不是静默替换为最终一致性。
13. 当已提交的数据库变更与外部事件交付必须可靠地一起完成时，使用 outbox。
14. 将 CQRS、Event Sourcing、repository 接口、独立表示层文件夹视为由任务证明其必要性的选择；根据项目调整示例命名和目录。
15. 交付所请求的模型、补丁或审查，并包含受影响的边界及解释这些边界的权衡。
16. 在适当层级验证变更后的不变量和适配器契约；架构问题不要求实现每一个模式。
17. 只加载当前正在做的决策对应的参考，而不是整套参考集合。
18. 涉及层放置、依赖方向、composition root 时加载 references/LAYERS.md。
19. 涉及限界上下文、通用语言、上下文映射时加载 references/DDD-STRATEGIC.md。
20. 涉及实体、值对象、聚合、repository 时加载 references/DDD-TACTICAL.md。
21. 涉及端口、驱动/被驱动适配器、替代布局时加载 references/HEXAGONAL.md。
22. 涉及 CQRS、事件、outbox、saga、Event Sourcing 时加载 references/CQRS-EVENTS.md。
23. 涉及领域测试、集成测试或架构测试设计时加载 references/TESTING.md。
24. 需要紧凑的模式与放置位置查询时加载 references/CHEATSHEET.md。
25. 需要基础理论时查阅 DDD、Hexagonal Architecture 和 Clean Architecture 的原始资料。

适用边界 · 注意事项

• 不适用于日常 CRUD 变更；简单 CRUD 可保持简单。
• 当用户明确指示优先，或任务不包含改变语言/架构时，不要擅自应用或改造架构。
• 业务不变量未知时，不要编造业务行为，也不要为局部修复强制要求发现工作坊。