用途
该技能用于审查一次代码变更的“领域形状”，即用领域驱动设计（Domain-Driven Design，DDD）的视角评估变更在领域边界、业务语言和内部结构上的合理性。其参考依据是 Vlad Khononov 所著《Learning Domain-Driven Design》（O'Reilly）。
它适用于以下情况：变更移动或跨越了限界上下文、修改了业务命名、引入了新的系统集成，或在单个上下文内部重构业务规则、聚合、值对象与领域事件。
两个审查层面
该技能在互补的两个层面上工作：
- 战略层面（Strategic，对应原书 Parts I、III–IV）：关注边界所在，包括限界上下文（bounded contexts）、通用语言（ubiquitous language），以及各上下文之间如何集成。
- 战术层面（Tactical，对应原书 Parts II–III）：关注单个上下文如何构建，包括业务逻辑模式，以及聚合和值对象是否守住其不变量、是否安全地发布领域事件。
两者可以组合使用：当一个变更同时涉及两个层面时，先做战略审查，再做受影响的战术规则检查，因为边界会约束内部设计。
使用方式
根据变更类型选择审查方式：
- 如果变更移动或跨越了限界上下文、改变了业务命名或集成了另一个系统，则读取
references/strategic-review.md。 - 如果变更在单个上下文内部组织业务逻辑、聚合、值对象或领域事件，则读取
references/tactical-review.md。 - 如果两者都涉及，先做战略审查，再做受影响的战术规则。
只应用相关的视角，不要生搬硬套。报告问题时给出文件与行号、所违反的规则以及建议的修复方案。对于干净的视角，不需要编造发现。
在进行审查之前，应先从仓库的服务/模块布局推导出上下文映射：物理的限界上下文通常对应后端服务/模块，每个上下文拥有一个模型和通用语言的一部分（例如事务核心服务、集成/同步服务、事件 worker、领域实体的共享内核、前端自己的 API 层模型）。子域（subdomain）是问题领域（如定价、调度、合规），限界上下文是模型与语言成立的解决方案边界，两者常常对齐但不总是对齐。
边界与区分
该技能有明确的适用范围，资料中说明了它不是以下工具：
- 不是通用的分层/内聚检查，也不是权衡/connascence 审计（这类任务应使用
architecture-lens）。 - 不是宏观风格选择或服务拆分（应使用
macro-architecture）。 - 不是缺陷排查（应使用
code-review）。
证据与输出
所选方法包含其独立的输出格式。报告时应先给出影响最大的发现，并区分“证据”与“尚未解决的领域决策”。
在 design-gate 场景下，保持只读，并返回其契约：verdict: proceed|revise、blocking_findings、advisory_findings 和 required_changes。应保留真实的不变量与集成边界；外观偏好属于建议性内容（advisory）。
详细参考文件
references/context-patterns.md：在分类上下文关系之前加载，或在某个发现需要其完整定义时加载。references/decision-trees.md：在模式分类处于边界情况时加载，或用于深入的聚合、值对象与事件检查。
暂未提供的信息
现有资料未提供该技能的具体安装命令、支持平台、收费与价格信息、使用步骤示例以及详细输出模板。这些内容暂未提供。