用途：审查一次代码变更的战略领域驱动设计（DDD）形状，关注有界上下文边界、通用语言命名漂移与跨上下文集成。与 ddd-tactical（上下文内模式）和 model-lens（通用分层检查）区分开。
主要能力（三个核心镜头）：
- 有界上下文边界：检查变更是否停留在单一上下文中，是否出现跨上下文连锁改动、模型渗透（直接访问其它服务内部实体/表而非发布接口或事件）、同一术语在不同上下文含义不同（边界信号）、边界大小是否按模型而非“最小服务”来确定。
- 通用语言：检查代码命名是否与业务术语一致，是否出现命名漂移、技术术语模型（如 status_int、flag2、misc_json）、同一概念多名称（vendor/supplier/seller）、边界处的基础类型强迫症；语言应保留在领域实体中，不被 HTTP/DTO/持久化形状重新定义。
- 上下文集成模式：判断并检查关系模式，包括防腐层 ACL（尤其对接外部 ERP 或第三方）、开放主机服务 OHS（消费者依赖发布契约，如 OpenAPI 生成的前端 API 层）、遵奉者、共享内核、各行其道，以及跨上下文异步集成（可靠发布/outbox、saga 或流程管理器）。
- 子域类型漂移：支持/通用子域转为核心子域（或反向）时调整投入，通用子域（认证、PDF、ERP 连接器）应集成而非自建建模。
使用方式：对变更应用相关镜头，按镜头分组输出发现，引用 file:line，指出规则名并提出修复；不适用的镜头可跳过，干净时明确写 clean。若仓库不是 greenspark-aws，先从服务/模块布局推导上下文映射再审查。可参考 references/context-patterns.md 获取模式定义与边界启发式。
适用场景：针对 greenspark-aws 类多服务后端（core-api、dispatch、erp-sync-workflow、eda-worker、compliance、pdf-generator、common/gslogic、frontend/client）的变更审查，或已推导出上下文映射的其它仓库。
限制：不检查上下文内部的战术模式（改用 ddd-tactical），不做通用分层检查（改用 model-lens）；不含具体的成本、性能或自动化程度声明；其它仓库需先自行建立上下文映射。资料未提供安装命令、定价、平台与效果数据。