Навыки ddd-context-mapping
📦

ddd-context-mapping

Безопасно

Сопоставление отношений ограниченных контекстов с паттернами DDD

Интеграция Domain-Driven Design становится сложной при взаимодействии нескольких ограниченных контекстов. Этот навык определяет четкие контракты и уровни защиты от внешнего влияния между контекстами с использованием проверенных паттернов DDD.

Поддерживает: Claude Codex Code(CC)
📊 71 Адекватно
1

Скачать ZIP навыка

2

Загрузить в Claude

Перейдите в Settings → Capabilities → Skills → Upload skill

3

Включите и начните использовать

Протестировать

Использование «ddd-context-mapping». Map relationships between Checkout, Billing, and Inventory contexts for an e-commerce platform

Ожидаемый результат:

  • Context Map: Checkout-Billing (Customer-Supplier, Billing owns contract)
  • Context Map: Checkout-Inventory (Partnership, shared contract ownership)
  • ACL required at Billing boundary to translate payment terms
  • Coupling risk: Inventory availability changes affect Checkout flow

Использование «ddd-context-mapping». Design integration between new Order context and legacy ERP system

Ожидаемый результат:

  • Pattern: Anti-Corruption Layer between Order and ERP
  • Order context defines canonical Order model
  • ACL translates ERP terminology to Order ubiquitous language
  • Contract tests validate ACL behavior for all ERP scenarios

Аудит безопасности

Безопасно
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
Контент
32
Сообщество
100
Безопасность
83
Соответствие спецификации

Что вы можете построить

Планирование интеграции микросервисов

Сопоставьте интеграцию контекстов Checkout, Billing, Inventory и Fraud перед реализацией границ сервисов.

Миграция устаревшей системы

Определите уровни защиты от внешнего влияния при интеграции новых предметных областей с существующими монолитными системами

Определение контрактов между командами

Проясните права владения восходящими и нисходящими потоками для предотвращения утечки предметной области и нечеткого распределения ответственности

Попробуйте эти промпты

Базовое сопоставление контекстов 
Проанализируйте мою предметную область с следующими ограниченными контекстами: [список контекстов]. Определите отношения между каждой парой и рекомендуйте подходящие паттерны сопоставления контекстов из DDD.
Проектирование уровня защиты от внешнего влияния 
Мне нужно интегрироваться с [внешняя система/контекст]. Спроектируйте уровень защиты от внешнего влияния, который переводит их модель в мой универсальный язык, защищая при этом мое ядро предметной области.
Матрица владения контрактами 
Создайте матрицу владения контрактами для этих пар контекстов: [список пар]. Определите, кто владеет каждым контрактом, какой перевод необходим и уровень риска связанности.
Анализ режимов отказа 
Для интеграции контекста [восходящий] в [нисходящий] с использованием паттерна [паттерн], определите режимы отказа, установите резервное поведение и политику версионирования.

Лучшие практики

  • Держите код уровня защиты от внешнего влияния на границах предметной области, а не внутри ядра предметной области
  • Добавьте контрактные тесты для проверки соответствия переведенного поведения ожидаемой семантике
  • Пересматривайте карты контекстов при изменении владения командой или границ предметных областей

Избегать

  • Разрешение нисходящим контекстам напрямую зависеть от внутренних моделей восходящих контекстов
  • Создание общих ядер между контекстами, которые должны оставаться независимыми
  • Пропуск уровней перевода при интеграции с внешними или устаревшими системами

Часто задаваемые вопросы

Когда следует использовать уровень защиты от внешнего влияния вместо паттерна Conformist?
Используйте ACL, когда восходящая модель конфликтует с вашим универсальным языком или при интеграции с внешними системами. Используйте Conformist, когда восходящая модель стабильна и соответствует вашим потребностям.
Сколько ограниченных контекстов должно быть в типичной системе?
Нет фиксированного числа. Контексты возникают из предметных областей и границ команд. Начните с основных бизнес-возможностей и разделяйте при обнаружении конфликтующих универсальных языков.
Может ли контекст иметь несколько паттернов отношений с другим контекстом?
Да, разные агрегаты внутри контекстов могут использовать разные паттерны. Документируйте каждое отношение отдельно, чтобы избежать путаницы.
Что такое Shared Kernel и когда его следует избегать?
Shared Kernel — это подмодель предметной области, разделяемая двумя командами. Избегайте его, когда контекстам нужна независимая эволюция или когда накладные расходы на координацию команд становятся слишком высокими.
Как обрабатывать версионирование при изменении контрактов контекстов?
Установите политику версионирования заранее. Поддерживайте обратную совместимость в периоды перехода. Используйте контрактные тесты для обнаружения критических изменений до развертывания.
Работает ли этот навык для монолитных приложений?
Да, ограниченные контексты могут существовать внутри монолитов как модульные границы. Сопоставление контекстов помогает планировать будущее извлечение сервисов и предотвращает утечку предметной области между модулями.

Сведения для разработчиков

Автор

sickn33

Лицензия

MIT

Репозиторий

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/ddd-context-mapping

Ссылка

main

Структура файлов

📁 references/

📄 context-map-patterns.md

📄 SKILL.md