clean-ddd-hexagonal

整洁架构、DDD 与六边形架构

使用这些相关模式解决具体的领域问题或依赖问题。这是一种带有倾向性的综合方案，并非强制的目录布局。用户的明确指示优先于本技能的指南。

选择范围

从所需行为、现有领域模型和当前依赖着手。除非任务要求更改，否则保留项目的语言和架构。简单的 CRUD 可以保持简单；团队规模、实体数量和文件长度都不能决定是否适合采用 DDD。

设计问题	相关模式
哪种语言和一致性规则描述了业务？	DDD、有界上下文、聚合
源代码依赖应指向哪个方向？	整洁架构／洋葱架构
应用如何使用不同的接口或基础设施？	六边形架构中的端口与适配器
读写是否需要不同的模型？	CQRS
是否必须根据事件历史重建状态？	事件溯源

如果业务不变量尚不明确，请指出具体缺失的规则，并继续处理不依赖该规则的工作。不要臆造业务行为，也不要为了局部修复而要求开展需求探索研讨会。

保留重要的边界

• 让领域行为独立于 HTTP、持久化和消息传递实现。将编排放在应用用例中，将外部 I/O 放在适配器中。
• 将实体标识与值对象相等性分开建模。根据事务不变量和争用情况选择聚合边界。
• 优先将事务限制在单个聚合内。如果需求要求跨聚合原子性，应明确说明这种权衡，而不是悄然将其替换为最终一致性。
• 如果必须确保数据库变更提交与外部事件投递同时可靠，请使用 Outbox。
• 将 CQRS、事件溯源、仓库接口和独立的展示层目录视为需要根据任务合理选择的方案。根据项目调整示例中的命名和目录。

交付所需的模型、补丁或审查结果，并说明受影响的边界及相应权衡。在适当的层级验证已更改的不变量和适配器契约；架构问题并不要求实现所有模式。

参考资料

根据要做的决策加载相应参考资料，而非加载整个资料集。

任务	参考资料
层的位置、依赖方向、组合根	LAYERS.md
有界上下文、通用语言、上下文映射	DDD-STRATEGIC.md
实体、值对象、聚合、仓库	DDD-TACTICAL.md
端口、驱动／被驱动适配器、替代布局	HEXAGONAL.md
CQRS、事件、Outbox、Saga、事件溯源	CQRS-EVENTS.md
领域、集成或架构测试设计	TESTING.md
紧凑的模式与位置速查表	CHEATSHEET.md

基础文献：DDD、六边形架构和整洁架构。