domain-driven-design

领域驱动设计

从 Learning Domain-Driven Design（Vlad Khononov，O'Reilly）中的视角审查变更的领域形态。DDD 在两个相互配合的层面上发挥作用：

• 战略层（第 I、III–IV 部分）——边界在哪里：限界上下文、通用语言，以及上下文如何集成。
• 战术层（第 II–III 部分）——如何构建一个上下文：业务逻辑模式，以及聚合／值对象是否能维护其不变量并安全地发布事件。

这不是通用的分层／内聚检查或权衡／共现性审计（使用 architecture-lens），不是宏观风格选择或服务拆分（使用 macro-architecture），也不是查找 bug（使用 code-review）。

选择审查方式

变更	阅读
移动或跨越限界上下文、更改业务命名，或集成其他系统	references/strategic-review.md
在一个上下文中组织业务逻辑、聚合、值对象或领域事件	references/tactical-review.md
两者兼有	先进行战略审查，再审查受影响的战术规则；边界会约束内部设计

只应用相关视角。报告发现时，注明文件和行号、规则以及建议的修复方案。视角检查未发现问题时，无需臆造发现。

**推导上下文映射：**物理上的限界上下文通常对应后端服务／模块，每个上下文都拥有一个模型和通用语言的一部分（例如，事务核心服务、集成／同步服务、事件工作器、领域实体共享内核、前端自己的 API 层模型）。审查前，先根据仓库的服务／模块布局推导这张映射。_子域_是一个问题领域（定价、调度、合规）；_限界上下文_是一个解决方案边界，在此边界内由一个模型／语言主导——两者通常一致，但并非总是如此。

证据与输出

所选方法包含其独立的输出格式。优先报告影响最大的发现，并区分证据与尚未解决的领域决策。

在 design-gate 下，保持只读，并使用调用方的规范门禁结果。保留实际不变量和集成边界；外观偏好仅供参考。

详细参考

• references/context-patterns.md：在对上下文关系进行分类，或发现问题需要完整定义时加载。
• references/decision-trees.md：在模式分类处于边界情况，或需要深入检查聚合、值对象和事件时加载。

在面试中，将决策、理由、约束和来源引用补充到现有决策记录中。独立报告和实现机制不适用于这一阶段。