Please enable JavaScript.

Coggle requires JavaScript to display documents.

DDD - Coggle Diagram

- - - - Виды
        
        Восходящий-нисходящий
        
        Конформист
        
        Нижестоящий обязан использовать модель вышестоящего и транслировать её в свою
        
        Вышестоящий не подчиняется нижестоящему
        
        Предохранительный уровень
        Anticorruption layer (ACL)
        
        Нет общей базы ядра
        
        Нет возможности поменять вышестоящего
        
        Нижестоящий адаптируется к вышестоящему
        
        Более полезен для поддержки вышестоящего как чёрного ящика
        
        Заказчик-поставщик
        Customer-supplier
        
        Тоже самое, что и конформист, только общие модели разрабатываются совместно для минимизации передаваемых данных
        
        OHS
        Open Host Service
        
        PL
        Published language
        
        Двунаправленные
        
        Партнёрство
        Partnership
        
        Нет общего кода
        
        Оба взаимозависимы
        
        Общее ядро
        
        Оба контекста имеют общее подмножество модели
        
        Ядро должно быть маленьким
      - Информация
        
        https://contextmapper.org/docs/language-model/
        
        https://www-culttt-com.translate.goog/2014/11/26/strategies-integrating-bounded-contexts?_x_tr_sl=en&_x_tr_tl=ru&_x_tr_hl=ru&_x_tr_pto=nui
        
        https://www.thereformedprogrammer.net/evolving-modular-monoliths-3-passing-data-between-bounded-contexts/
- - - - DDD quickly
      - Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем
      - Презентации
        
        https://slides.silverfire.me/2017/eatdog-ddd/#/113
    - - Реализация методов предметно-ориентированного проектирования
      - Предметно-ориентированное проектирование. Самое основное
  - - - Часть 1
      - Часть 2
- - - - Собирательная сущность которая считается единым целым
      - Состоит из VO и Entity
      - Определяется по идентификатору
      - Является границей транзакции при изменении данных (Данные должны изменяться в рамках одной транзакции)
      - Другие элементы домена не могут ссылаться на внутренности агрегата
      - Один Entity не может быть в двух агрегатах одновременно
      - Признаки правильно выбранного корня агрегата
        
        Не должен пересекать границы предметного контекста
        
        Есть объект в реальном мире
        
        Есть ли инвариант для данной группы объектов
        
        Данные должны изменяться в рамках одной транзакции?
    - - индивидуальность
      - жизненный цикл
      - Один Entity не может быть в двух агрегатах одновременно
        
        Такой Entity должен стать агрегатом
      - Внедрение доменной службы в объект
        
        Внедрение службы нечистого домена в сущности нарушает изоляцию, поэтому я бы не рекомендовал это делать.
        
        С другой стороны, чисто доменная служба не причиняет никакого вреда, поэтому вполне нормально ссылаться на них из ваших сущностей и объектов значений.
    - - никогда не меняется
      - нет индивидуальности
        
        Не обладает идентификатором
      - Валидирует, порождает себя
      - Умеет сравнивать себя с другими
    - - Операция не имеет состояния
      - Сервисы предоставляют приложению интерфейсы для работы с доменом
      - Выносятся только знания, которые не относятся к Entity. Иначе возникает анемичная модель
        
        Операция, выполняемая службой, относится к концепции предметной области, которая не принадлежит ни одной из существующих сущностей
        
        Содержат методы, описывающие операции домена (содержит доменные знания)
        
        Оперировать логикой, которая не укладывается в существующую сущность
      - Могут обращаться к репозиториям и другим сервисам
      - Уносят логику из контроллеров
      - Операция выполняется над различными объектами модели предметной области
      - Возможно не записывает сущность через репозиторий
    - - Описывается только интерфейсом
      - создаются только для агрегатов
      - Виды репозиториев
        
        Storage-Like Repository
        
        Collection-Like Repository
      - Имеет семантику коллекции
      - Возвращает валидные сущности
      - Доменно-специфичные методы
      - Изолирует домен от БД
    - - Используется для создания сложных сущностей, чтобы убрать эту бизнес-логику из уровня службы приложения
      - Информация
        
        https://habr.com/ru/post/316890/
        
        https://medium.com/walmartglobaltech/implementing-cart-service-with-ddd-hexagonal-port-adapter-architecture-part-2-d9c00e290ab#2261
        
        https://www.culttt.com/2014/12/24/factories-domain-driven-design
      - Если сущность является чисто представлением данных, хранящихся локально в микросервисе, этого достаточно и нет необходимости в Factory
      - Использовать когда сущность являются смесью данных из внешних служб
    - - Нужно использовать, когда необходим ответ от другого контекста
      - Фреймворки
        
        spatie/laravel-event-sourcing
      - Пример
    - - Служит для выборки сущностей
      - Можно выбирать по сложным критериям
      - Разрежает контракт репозитория (Interface segmentation principe)
      - Может объединяться с друзьями-спецификациями
      - Может содержать порождающую логику
      - Можно валидировать через неё
    - - Точка входа в сервис
        
        Объединяет все сервисы домена, чтобы соответствовать Single Responsibility
      - Выполняет законченную бизнес-транзакцию
      - Принимает и возвращает
        
        VO или более сложные DTO
        
        Для построения можно использовать шаблон Builder
        
        Примеры kommerce-core/src/EntityDTO/Builder
        
        DTO строят мапперы
        
        Пример
        
        Почему-то их называют ещё ассемблеры
        
        Пример 2
        
        Валидация входящих данных
        
        Валидация входных данных
        
        http://gorodinski.com/blog/2012/05/19/validation-in-domain-driven-design-ddd/
        
        Валидация через бизнес-правила
        
        Через фабричный метод
        
        Через фабрику
        
        Через составное исключение
        
        Предпочтительнее все данные для создания сущности переводить в поведения новых сущностей, в бизнес-правила
        
        Валидация данных должна быть на уровне AL, а бизнес-правил на DL
        
        Хороший ответ на вопрос
        
        В modular-monolith-with-ddd это реализовано через класс IBusinessRule
        
        Пример отдельной валидации DTO через валидатор
        
        Фреймворки для валидации
        
        https://github.com/beberlei/assert
        
        https://github.com/webmozarts/assert
        
        https://github.com/awurth/SlimValidation
        
        Объект запроса\ответа
        
        Пример
      - Возвращает результат в виде доменных событий или ошибок
      - Что должен делать
        
        Не содержит состояния
        
        Не содержит доменных знаний (цикломатическая сложность 1 цикл)
        
        Делегирует сложности доменным сервисам или сущностям
      - Работает только в рамках своего ограниченного контекста
      - Если операцию можно выполнить неразрывно, то это предметная логика, иначе - прикладной уровень
      - Можно реализовать в виде обработчика команд
        
        Хороший пример можно посмотреть в kommerce-core
    - - Не содержит бизнес-логику
      - Только аггрегирует данные из других сервисов
  - - - Смысловое ядро – это подобласть, имеющая первостепенное значение для организации
      - служебной подобласти (Supporting subdomain)
        
        Бизнес создает служебную подобласть, потому что она имеет специализацию
      - неспециализированной подобластью (Generic subdomain)
        
        Если она не имеет специального предназначения для бизнеса, а требуется для всего бизнеса в целом,