Функциональные требования: Domain Drive Design (продолжение)

Давайте попробуем разобраться, как можно разработать наш mvp через доменный подход.

Заказчик всегда формирует мысли и требования через процедурный подход. Это нормально. Наша задача – произвести правильную декомпозицию и систематизировать эти требования в конкретные реализации.

В этом подходе мы декомпозируем наши функции в первую очередь на основные сущности, в данном случае это клиент, продукт, заказ. Заметьте: тут нет корзины, потому что корзина по факту – это тот же самый заказ. На этом этапе мы разрываем логическую связь. Это первый важный шаг.

За пределами наших доменов уже будут различные внешние информационные системы, такие как складская система или система доставки.

Таким образом, мы идем не от конкретных потребностей, а делим зоны на явные области ответственности или контексты.

Domain Drive Design говорит, что работать нам надо в ограниченных контекстах, тем самым снижать зависимости и быть более гибкими.

Домены – это сущности и процессы реального мира, которые нужно автоматизировать.

Домены могут делиться на следующие категории: 1⃣ Subdomain – часть общего домена с конкретной выделенной частью. 2⃣ Core domain – смысловое ядро. 3⃣ Support Domain – вспомогательный домен. 4⃣ Generic Domain – общий домен.

Чтобы правильно определить доменные области, в первую очередь нужно правильно выделить основные бизнес-сущности (entity).

Сущность должна иметь набор обязательных атрибутов, которые соответствуют нашему бизнес-объекту. Она может быть изменяемая. Обязательно имеет идентификатор, по которому мы можем сравнить сущности.

Помимо сущностей для правильного выделения области домена нужно выделить объект-значение (value object). Эти объекты неизменяемы и сравнение происходит путем сравнения атрибутов и значения в них. Все атрибуты должны проходить валидацию, и такие объекты не имеют идентификатора.

Если смотреть на примере нашего mvp, основная разница между сущностями и объектами значений заключается в продукте, который заказывает клиент. Если в случае заказа конкретного товара/продукта нам важны только его атрибуты (размер, цвет, количество), которые должны соответствовать выбору пользователя, то в случае возврата нам уже важен его идентификатор.

В реальном мире мы работаем в основном через агрегаты, когда у нас есть основная сущность, и уже сущность связана с value object’ами. И все это область одного домена.

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

Сегодня мы погрузились в разработку требования по принципу DDD. Мы выделили проблемы процедурного подхода, научились выделять доменные области и смотреть на требования через них.

Мой канал - https://t.me/carbonka