DDD и ограниченные контексты

Моделирование по философии Domain Driven Design. Понятие доменной модели. Исследование предметной области и выделение ограниченных контекстов.

  • 00:00:37 Постановка задачи
  • 00:01:09 Аббревиатура DDD
  • 00:01:45 Модель солнечной системы
  • 00:04:32 Пример ларька с шаурмой
  • 00:06:26 Подобласти бизнеса
  • 00:07:44 Единый язык
  • 00:08:29 Отражение бизнеса в коде
  • 00:09:32 Разделение данных
  • 00:14:14 Ограниченные контексты
  • 00:15:27 Разделение на модули по контекстам
  • 00:16:52 Анализ бизнеса в DDD
  • 00:18:16 Автоматизация процессов вместо данных
  • 00:19:07 DDD не про код
  • 00:20:40 Применение к нашему проекту
  • 00:22:59 Связанность и рост проекта
  • 00:24:44 Удобство деления на микросервисы
  • 00:25:54 Риск неверного разбиения
  • 00:27:03 Что в итоге

Анализ бизнеса аукциона мы проведём отдельно в серии о техзадании.

Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru

Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram

Комментарии (30)
Arunas
2020-01-18 15:10

Спасибо.

Ответить
Denis
2020-01-18 19:28

Это прекрасно.

Ответить
Ruslan
2020-01-18 20:01

Стало еще лучше, появились картинки :) . Мне не хватало рисунков в разработке рабочего места и деплоя. Прожал на будущую кнопку "лайк".

Ответить
Руслан
2020-01-19 06:51

Спасибо, все лаконично и этим круто, и отдельное спасибо за kleki. Также недавно открыл для себя draw.io, удобно набрасывать схемки клиенту с любого устройства.

Ждем с нетерпением картинок с кодом :)

Ответить
drakulitka
2020-01-20 10:33

Спасибо!!! А почтовый сервер будет подниматься в этом мастер-классе или будут заглушки?

Ответить
Дмитрий Елисеев
2020-01-22 16:32

Будут заглушки для девелопмента.

Для борьбы с антиспамом удобнее использовать сторонние сервисы, чем поднимать савой почтовик.

Ответить
Arunas
2020-01-20 19:17

Да, было бы круто почтовый сервер (напр. image: tvial/docker-mailserver:latest) и UI с ROUNDCUBEMAIL_DB_TYPE=pgsql....

Ответить
Александр
2020-01-26 06:52

Спасибо, Дмитрий.

Ответить
Роман
2020-02-14 13:57

Спасибо за подробно изложенный материал!

Ответить
Максим (@myks92)
2020-05-08 23:39

Доброй ночи, Дмитрий! С праздником 9 мая!)

Проектируя по DDD ограниченными контекстами решил выделить все справочники в отдельный контекст: Справочники (Dictionaries). И появилось несколько вопросов:

  1. Уместно ли такое название для справочников? Какое название используете вы?
  2. В справочник у меня ушли: категории мероприятий, категории организаций, страны регионы города, пол человека и так далее. В других сервисах я ссылаюсь на этот справочник только по ID (Category ID). Правильно ли это? Вы говорили, что сервис должен быть полностью независим. А тут вроде как зависимость. если не сложно - поясните)
Ответить
Дмитрий Елисеев
2020-05-13 11:11

В других сервисах я ссылаюсь на этот справочник только по ID (Category ID). Правильно ли это?

Правильно. Должно быть только указание ID. Это не связь с самим объектом.

В справочник у меня ушли: категории мероприятий, категории организаций, страны регионы города, пол человека и так далее.

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

Категории мероприятий имеет смысл оставить в мероприятиях, если они используются только там и без мероприятий они никому больше не нужны. Категории организаций оставить в организациях. А страны с регионами и городами уже можно вынести в контекст Geo.

Ответить
Максим (@myks92)
2020-05-13 13:40

Благодарю! А если категории мероприятий используется в двух местах?

Ответить
Дмитрий Елисеев
2020-05-13 15:44

Тогда уже можно вынести.

Ответить
Максим (@myks92)
2020-05-15 06:13

Отлично. Это уяснил. Дмитрий, ещё появился такой интересный вопрос. Думаю, будет интересно будет услышать этот ответ на вопрос в вашем уроке по проектированию доменных сущностей.

В своих уроках вы часто используете в качестве ID - UUID. Но везде использовать UUID не даёт понимания при анализе базы данных. Поэтому некоторые ID формируют более смысловые. Например первый символ может быть Первой буквы названия сервиса. Или используя сущность + другие значения. В итоге из тематики медицины есть такой пример: PatientTHX1138

Если не сложно включите небольшой разбор в свои лекции про генерацию UUID, а так же как это можно делать на системах, которые уже работают. На сколько знаю ID не меняется, как и не удаляются данные, из-за соблюдения консистенции данных. В таком случае придётся делать поле CODE, если правильно мыслю)

И можно ли использовать SLUG в качестве ID? Только вот проблема. Слуг иногда меняется. Например у пользователя или организации.

Ответить
Дмитрий Елисеев
2020-05-19 12:48

Но везде использовать UUID не даёт понимания при анализе базы данных. Поэтому некоторые ID формируют более смысловые.

С точки зрения самой БД идентификаторы в анализе практически не нуждаются, так как лежат в своих таблицах и полях и никто напрямую смотреть на БД обычно не заходит.

Например первый символ может быть первой буквой названия сервиса.

А потом вдруг захочется переименовать сервис и такие идентификаторы придётся тоже переименовывать.

В итоге из тематики медицины есть такой пример: PatientTHX1138. И можно ли использовать SLUG в качестве ID?

Это всё определяет вопрос, какой идентификатор использовать: суррогатный (UUID, Auto Increment) или естественный (slug, email, patient). В случае суррогатного его формат не важен и значение точно никогда не изменится.

А с пользовательскими уже сложнее. Например, для записи PatientTHX1138 таблицу patients можно создать с составным первичным ключом (id=1138, type=TNX).

Так что либо UUID или Auto Increment, либо что-то своё, либо хранить одновременно UUID для связей + что-то другое вроде slug для отображения посетителю.

Ответить
Максим (@myks92)
2020-05-16 20:40

И ещё забыл уточнить. Важный момент. У меня много категорий для мероприятий, для организаций, для дисциплин. У меня есть два пути: 1. В категории добавить type и указывать (type = events, discipline, organization). В этом случае большой плюс, что не надо будет городить много сущностей, верстки и т.п. 2. Каждая категория отдельно, но так как большинство будут использоваться в 2-х и более местах придется поместить в справочник. Тогда будут названия сущностей вроде EventCategory OrganizationCategory...

Какой подход 1 или 2 лучше?

Ответить
Дмитрий Елисеев
2020-05-19 13:04

Если разделять, то больше гибкости, так как можно программировать их со своими нюансами независимо. В этом случае проблема лишней вёрстки и кода частично решается разработкой общих виджетов и сервисов, работающих с interface Category или TreeCategory и подобными обобщениями. Если не разделять, то сэкономим на коде, но везде будем таскать type. Так что вопрос выбора сложный.

Ответить
Дмитрий
2021-06-06 14:43

А подскажите, пожалуйста, как поступить в ситуации, если у сущности в различных состояниях могут быть (не)заполнены какие-то поля? Например, возьмём модель такси, там есть сущность заказа, у которой при статусе new поле driver пустое, но через какое-то время водитель берёт заказ и заказ переходит в статус booked. Т.е. получается статус заказа и водитель являются неким инвариантом, при каком-то статусе водителя нет, а при каком-то есть. Т.е. если подходить к вопросу в лоб, то не получается соблюсти данный инвариант:

class Order {
   private Status $status;
   private ?Driver $driver = null;
  ....
}

Как можно побороть такую ситуацию в общем случае? (данная модель дана для примера)

Ответить
Дмитрий Елисеев
2021-06-07 12:13

Для каждой операции делаем метод, переводящий всё сразу в новое состояние:

class Order
{
    ...

    public function bookBy(Driver\Id $driver, DateTimeImmutable $date): void
    {
        if ($this->status->isBooked()) {
            throw new DomainException('Order is already booked.');
        }
        $this->status = Status::booked();
        $this->bookedAt = $date;
        $this->driver = $driver;
    }
}

и в нём производим все заполнения с проверками.

Но вместо одного большого класса Order можно разбить процессы на несколько более мелких классов. Тогда взятие заказа можно производить отдельным классом Booking:

$booking = new Booking($orderId, $driverId, $date);

Тогда внутри Booking эти поля будут сразу обязательными.

Ответить
Дмитрий
2021-06-07 13:59

Да, отдельным классом наверно это хорошее решение. Т.к. тогда это решит проблему, что $order->getDriver() когда-то есть, а когда-то нет. Спасибо.

Ответить
Дмитрий Елисеев
2021-06-07 14:57

С одним классом с методами:

public function isBooked(): bool
public function getDriver(): ?Driver

тоже проблемы нет.

Ответить
Дмитрий
2021-06-08 16:24

Да, но тогда как решить проблему?

if ($order->isBooked()) {
    // type: ?Driver, а хотелось бы просто Driver
    $driver = $order->getDriver(); 
}
Ответить
Дмитрий Елисеев
2021-06-09 16:55

Если это проблема, то решить как:

public function getDriver(): Driver
{
     return $this->driver ?? throw new BadMethodCallException('Driver is not set.');
}
Ответить
Андрей
2021-06-17 10:30

Добрый день, Дмитрий!

Хотел бы узнать ваше мнение по правильному применению практик DDD.

У моем проекте модель предметной области DDD разделена на 3 модуля, каждый из которых размещен в собственном каталоге (условно Model1, Model2, Model3). Должны ли корневые сущности-агрегаты моделей всех 3-х модулей реализовывать один общий интерфейс RootAggregateInterface или допустимо, чтобы каждый из 3-х модулей реализовывал свой собственный интерфейс RootAggregateInterface со своими индивидуальными методами, необходимыми только конкретному модулю?

Ответить
Дмитрий Елисеев
2021-07-07 14:45

Допустимо выносить общие системные вещи. В случае разнесения моддулей на отдельные микросервисы такие вещи просто выносятся в composer-пакеты и подключаются к каждому проекту.

Ответить
Андрей
2021-10-07 17:09

Добрый день, Дмитрий!

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

Правильно ли я понимаю, что, например, в Вашем подходе к разработке на Slim классы сущностей относятся к уровню модели, классы репозиториев и Fluser - к инфраструктурному уровню, классы внутри UseCase (Command, Handler) - к операционному уровню, а классы Action - к презентационному уровню.

Одним словом, хотелось бы увидеть что-то типа этого.

Спасибо за вашу работу.

Ответить
Дмитрий Елисеев
2021-10-08 10:18

Очень не хватает обзорного видео по общим принципам DDD

Принципы DomainDD - это единый язык с бизнесом и ограниченные контексты. Аналогично с этим TestDD лишь призывает писать тесты до кода. А BehaviorDD призывает делать тесты, описывающие поведение системы на человекопонятном языке, а не в техническом виде. Как именно писать сам код тестов эти практики явно не говорят.

То есть стратегический DDD говорит лишь про организацию разработки, а не про программный код. А дальше уже тактический DDD всего лишь говорит, какие уже существующие паттерны будет удобно использовать для этих целей.

Хотелось бы услышать о луковичной, гексагональной и иных архитектурах приложения

Это просто варианты чистой архитектуры, которые у себя можно использовать для написания фреймворконезависимого кода. Которые всё взаимодействие чистого ядра со внешним миром производят через адаптеры.

Правильно ли я понимаю, что, например, в Вашем подходе к разработке на Slim классы сущностей относятся к уровню модели

Про разделение на уровни обсуждали здесь и здесь в комментариях к другим эпизодам. Ещё про эти уровни говорил в докладе.

Горизонтальное разделение на уровни нам менее важно, чем вертикальное разделение на модули.

Ответить
Андрей
2021-10-13 13:17

Дмитрий, спасибо за Ваш развернутый ответ.

Заинтересовала Ваша схема в комментариях с разбиением по слоям:


Application
    Command
    Query

Domain
    Entity
        class Id
        interface UserRepository
    Service
        interface PasswordHasher
    interface Flusher

Infrastructure
    Entity
        class IdType
        class DoctrineUserRepository implements UserRepository
    Service
        class CryptPasswordHasher implements PasswordHasher
    class DoctrineFlusher implements Flusher

Возник вопрос: в каком пространстве имен правильно будет располагать интерфейсы доменного уровня: interface UserRepository, interface PasswordHasher и interface Flusher? Все интерфейсы расположить в одном пространстве имен \App ? Или существует какой-то более грамотный подход?

Ответить
Дмитрий Елисеев
2021-10-19 07:53

Для простого приложения можно именовать всё по папкам от корневого App:

App\Application
App\Domain
App\Infrastructure

Но вместо App можно папке src присвоить нэймспейс по имени приложения:

Blog\Application
Blog\Domain
Blog\Infrastructure

Если приложение модульное, то можно делать модули внутри App:

App\Blog\Domain
App\Comment\Domain

либо обходиться без App:

Blog\Domain
Comment\Domain

Это дело вкуса.

Ответить
Крутые и полезные вещи объясняете, спасибо!
2024-02-08 00:56

Очень полезно, спасибо!

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Yandex
MailRu
© 2026 Елисеев Д.Н. ИНН 570600870325