Стратегические паттерны DDD 2

1.

Стратегические паттерны

2.

3.

задач
Карта контекстов
Пространство
решений
e-Commerce system
External
Forecasting
system
Inventory
system

4.

Ограниченный контекст
(Bounded Context)

5.

Ограниченный контекст – контекст
существования модели
Модель не может существовать вне контекста
Другие контексты содержат другие модели и
другие диалекты общеупотребительного
языка
Ограниченный контекст в DDD
крупномасштабная зона ответственности

6.

Модель предметной области – король
Король должен быть защищен

7.

Страховые полисы для пособий по
нетрудоспособности следует рассматривать,
принимая во внимание следующие элементы
1.
2.
3.
4.
5.
6.
7.
8.
9.
Расценки и продажи
Общий процесс работы с полисом (продление,
прекращение)
Оценка выплат за аудит
Ежеквартальные оценки
Установка и поддержание ставок
Выплата комиссий агентам и брокерам
Получение выплат от клиентов
Общая бухгалтерия
Определение допустимых рисков (андеррайтинг)

8.

Все это можно включить в единую монолитную
систему, но это приведет нас к потери ясности
Полис в контексте общего рабочего процесса и в
контексте аудита выплат, совершенно разные вещи
Если использовать один и тот же класс, профиль
этого класса станет очень велик и мы далеко уйдем
от проверенных и действительно оптимальных
приемов, таких, как принцип персональной
ответственности (SRP)

9.

Системы, в которых не удается
разделить и изолировать
ограниченные контексты, часто
приобретают архитектурный
стиль, который имеет
красноречивое название
«Большой ком грязи»
«Большой ком грязи (Big Ball of Mud)»
1999 г. Брайан Фут (Brian Foot) и Йозеф Йодер (JosephYoder)

10.

Возможны пересечения важных понятий, а
отсюда трудности в понимании, какую
модель нужно использовать в задаче
Запутываются коммуникации между
членами группы
Возникают дублирующиеся понятия и
ложные родственники
Работа программы становиться
ненадежной, если в ней, одновременно
используются объекты из разных моделей

11.

Правил определения контекста не
существует, но всем должны быть
известны правила ограничивающие
контекст
Основное качество ограниченного контекста
– поддержка границы
Если это требует нарушения принципа
DRY («не дублируй себя»), принцип DRY
должен быть нарушен

12.

Ограниченный контекст не идентичен модели
смыслового ядра
В результате ошибок (особенностей)
проектирования
В идеальном проекте DDD между подобластями и
ограниченными контекстами должно быть
установлено однозначное соответствие
Ограниченный контекст включает в себя
модули разных слоев, не только слоя бизнес
логики

13.

Ограниченный контекст называется по
имени подобласти которою содержит

14.

Карта контекста
(Context Map)

15.

Для исследования границ нашей системы
можно использовать простую схему, которая
называется картой контекста
Перечисление контекстов
2. Указание связей между ними
1.
Карта контекста фиксирует существующую
ситуацию

16.

У каждого контекста есть собственный
общеупотребительный язык

17.

Strategic Domain Driven Design with
Context Mapping [Alberto Brandolini]

18.

19.

20.

Взаимосвязи контекстов

21.

Взаимодействие между разными командами может привести к проблемам

22.

При наличии нескольких взаимодействующих контекстов необходимо
формировать отображения контекстов друг в друга

23.

Две команды используют общую доменную модель для организации
взаимодействия
Самый сложный с точки зрения поддержки вариант

24.

Одна из команд предоставляет сервисы (фиды) другой
Тестирование и разработка интерфейсов требует совместной работы

25.

Отношения вышестоящий-нижестоящий
(upstream-downstream) фиксируют слияние
одного контекста на другой
Вышестоящий контекст (U) оказывает
влияние на нижестоящий
Нижестоящий контекст (D) не оказывает
влияние на вышестоящий
Реализации
Пользователь/Заказчик (Customer/Supplier)
Конформизм (Conformist)

26.

Одна из команд подстраивается под второю, предоставляющую
сервисы
Качество модели первой команды, при этом, сильно зависит от
качества модели второй

27.

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

28.

Интеграция всегда обходится дорого, а
отдача от нее не всегда велика
Объявите ОГРАНИЧЕННЫЙ никак не
связанным с другими контекстами
Это позволит разработчикам найти
простые узкоспециализированные
решения в данном ограниченном
пространстве

29.

Применяется как паттерн для
унаследованных систем
Система не упорядочивается, но
ограничивается и не оказывает
существенного влияния но вновь
создаваемый код

30.

31.

Службы с открытым протоколом
Open Host Service (OHS)
Например RPC
Если подсистему необходимо интегрировать со многими
другими, необходимость построения отдельного
транслятора для каждой из других систем становится
тяжким бременем
Общедоступный язык
Published Language (PL)
Например XML
Прямая трансляция из существующей модели предметной
области в нее может оказаться неудачным решением
или

32.

Карта контекста фиксирует
существующее решение
Не все проблемы могут быть
разрешены

33.

Карта контекстов представляет
архитектуру предприятия
нет
Карта контекстов представляет топологию
системы
нет

34.

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

35.

Антикоррупционный слой
(Anticorruption Layer)

36.

Имена
Слой, предохраняющий абстракцию (ACL)
Предохранительный уровень
Определение
Схема DDD, в которой предлагается
создавать фильтры, не дающие концепциям
из другой предметной области просочиться
в вашу модель
Поддерживает чистоту модели

37.

Придает нужный смысл объектам из другой по
семантике модели
Делает менее чувствительной модель к изменениям
из вне
Упрощает интерфейсы взаимодействия между двумя
системами
Содержит методы специфичные для взаимосвязи
двух подсистем
Содержит необходимые инварианты для контроля
поступления внешних данных
Основные шаблоны для реализации: Facade, Adapter

38.

В сущности, репозитории —
разновидность ACL
Они оставляют снаружи вашей модели SQL
или конструкции объектно-реляционного
сопоставления (ORM)

39.

ACL — отличный способ для введения
швов
Шов — это зона, где можно начать
убирать устаревший код и вносить
изменения
Выделение швов, как и изоляция
основной предметной области, могут
быть очень выгодны при использовании
методов DDD для рефакторинга и
усиления наиболее значимых частей
кода
Эффективная работа с унаследованным кодом
[Майкл Физерс (Michael Feathers)]

40.

Четко обозначить контуры модели,
определить ее первостепенный смысл
Сформулировать концепции, для добавление
в модель новых понятий
Избегать зависимостей с объектами других
моделей
Взаимодействовать с другими моделями,
только через предохранительные уровни
Постоянно контактировать с разработчиками
других моделей, с целью выделения общего
ядра

41.

Any 3rd party system that I
have to integrate with was
written by a drunken monkey
typing with his feet
Oren Eini aka Ayende