技能 ddd-context-mapping
📦
ddd-context-mapping
安全
使用 DDD 模式映射限界上下文关系
当多个限界上下文交互时，领域驱动设计的集成变得复杂。此技能使用经过验证的 DDD 模式定义上下文之间的清晰契约和防腐层。
支持: Claude Codex Code(CC)
1
下载技能 ZIP
2
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
3
开启并开始使用
测试它
正在使用“ddd-context-mapping”。 映射电子商务平台中 Checkout、Billing 和 Inventory 上下文之间的关系
预期结果:
- 上下文映射：Checkout-Billing（客户 - 供应商，Billing 拥有契约）
- 上下文映射：Checkout-Inventory（合作伙伴关系，共享契约所有权）
- 在 Billing 边界需要 ACL 来翻译支付条款
- 耦合风险：Inventory 可用性变更会影响 Checkout 流程
正在使用“ddd-context-mapping”。 设计新 Order 上下文与遗留 ERP 系统之间的集成
预期结果:
- 模式：Order 和 ERP 之间的防腐层
- Order 上下文定义规范订单模型
- ACL 将 ERP 术语翻译为 Order 通用语言
- 契约测试验证 ACL 在所有 ERP 场景下的行为
安全审计
安全v1 • 2/24/2026
Static analysis flagged markdown backticks as shell commands and weak cryptography patterns. All findings are FALSE POSITIVES - the skill contains only documentation and reference material with no executable code, network calls, or filesystem operations. Safe for publication.
2
已扫描文件
78
分析行数
0
发现项
1
审计总数
未发现安全问题
审计者: claude
质量评分
41
架构
100
可维护性
87
内容
50
社区
100
安全
83
规范符合性
你能构建什么
微服务集成规划
在实现服务边界之前，映射 Checkout、Billing、Inventory 和 Fraud 上下文如何集成。
遗留系统迁移
在将新领域与现有单体系统集成时定义防腐层。
跨团队契约定义
明确上游和下游所有权，防止领域泄漏和职责不清。
试试这些提示
基本上下文映射
分析我的领域，包含以下限界上下文：[list contexts]。识别每对上下文之间的关系，并从 DDD 中推荐合适的上下文映射模式。
防腐层设计
我需要与 [external system/context] 集成。设计一个防腐层，将其模型翻译为我的通用语言，同时保护我的领域核心。
契约所有权矩阵
为以下上下文对创建契约所有权矩阵：[list pairs]。定义每个契约的所有者、所需的翻译以及耦合风险级别。
故障模式分析
对于使用 [pattern] 的 [upstream] 到 [downstream] 上下文集成，识别故障模式、定义回退行为并建立版本控制策略。
最佳实践
- 将防腐层代码放在领域边界，而非领域核心内部
- 添加契约测试以验证翻译后的行为是否符合预期语义
- 当团队所有权或业务领域变更时重新审视上下文映射
避免
- 允许下游上下文直接依赖于上游内部模型
- 在本应保持独立的上下文之间创建共享内核
- 在与外部或遗留系统集成时跳过翻译层
常见问题
我应该何时使用防腐层与遵从者模式？
当上游模型与你的通用语言冲突或与外部系统集成时使用 ACL。当上游模型稳定且符合你的需求时使用遵从者 (Conformist) 模式。
一个典型系统应该有多少个限界上下文？
没有固定数量。上下文从业务领域和团队边界中涌现。从主要业务能力开始，当你发现通用语言冲突时再进行拆分。
一个上下文可以与另一个上下文有多个关系模式吗？
是的，上下文内的不同聚合可以使用不同的模式。分别记录每个关系以避免混淆。
什么是共享内核，我何时应该避免使用它？
共享内核 (Shared Kernel) 是两个团队共享的领域模型子集。当上下文需要独立演进或团队协调开销过高时应避免使用。
当上下文契约变更时我如何处理版本控制？
提前建立版本控制策略。在过渡期间支持向后兼容。使用契约测试在部署前检测破坏性变更。
这个技能适用于单体应用吗？
是的，限界上下文可以作为模块边界存在于单体应用中。上下文映射有助于规划未来的服务提取并防止跨模块的领域泄漏。