Теоретическая часть

Доменно-ориентированный дизайн (Domain-Driven Design, DDD) — это подход к разработке программного обеспечения, который ставит в центр внимания предметную область (домен) и бизнес-логику системы. Основная цель DDD заключается в том, чтобы создать программное обеспечение, которое точно отражает сложность и нюансы домена, над которым оно работает. Важнейший аспект DDD — это глубокое взаимодействие разработчиков и экспертов по домену (бизнес-аналитиков, пользователей и т.д.) для создания модели, которая будет основой архитектуры системы.

Основные понятия DDD

1. Домен (Domain) — это область знаний, на которую направлено программное обеспечение. Примером домена может быть банковская система, торговая платформа, система управления складом и т.д.

2. Модель (Model) — абстракция или упрощение реального домена, которая позволяет описать его в терминах, понятных и программистам, и экспертам по домену.

3. Единый язык (Ubiquitous Language) — общий язык, который используется всеми участниками проекта (разработчиками, аналитиками, клиентами). Он должен основываться на понятиях и терминах из домена, чтобы минимизировать недопонимания.

4. Ограниченные контексты (Bounded Contexts) — логические области внутри системы, где определенные термины и модели имеют конкретное значение. Каждый ограниченный контекст имеет свои границы и может использовать свои собственные модели.

5. Сущности (Entities) и Значимые объекты (Value Objects) — ключевые строительные блоки модели. Сущности имеют уникальную идентичность, которая сохраняется во времени (например, клиент в системе), а значимые объекты характеризуются своим состоянием, но не имеют уникальной идентичности (например, адрес клиента).

6. Агрегаты (Aggregates) — группы связанных сущностей и значимых объектов, которые рассматриваются как единое целое. Агрегаты помогают управлять сложностью и обеспечивают консистентность данных внутри себя.

7. Службы (Services) — объекты или компоненты, которые выполняют операции, выходящие за рамки одной сущности или агрегата, и не могут быть отнесены ни к одному из них.

8. Репозитории (Repositories) — объекты, отвечающие за хранение и извлечение сущностей и агрегатов из базы данных. Репозитории позволяют работать с сущностями, не заботясь о том, как они хранятся.

9. События домена (Domain Events) — факты или изменения, произошедшие в домене, которые могут быть важны для других частей системы.

Пример на Пальцах

Представим, что мы разрабатываем систему для интернет-магазина.

1. Домен: Интернет-магазин. Основные аспекты домена: управление товарами, заказами, пользователями и оплатами.

2. Единый язык: Мы договариваемся использовать следующие термины: «товар», «корзина», «заказ», «оплата», «клиент».

3. Ограниченные контексты:

   • Контекст каталога товаров: Здесь мы работаем с понятием «товар», его характеристиками, ценами и наличием.
   • Контекст заказов: В этом контексте понятием «товар» может рассматриваться как позиция в заказе. Это отдельная модель с другими свойствами, такими как количество, цена на момент заказа и т.д.
   • Контекст пользователей: Здесь мы управляем данными о клиентах, их адресах, платежной информации и т.д.

4. Сущности и Значимые объекты:

   • Сущности: Клиент, Заказ.
   • Значимые объекты: Адрес клиента, Позиция заказа (товар в заказе).

5. Агрегаты:

   • Агрегат «Заказ» может включать сущности «Клиент», «Позиция заказа» и значимые объекты, такие как «Адрес доставки» и «Метод оплаты».

6. Службы:

   • Служба «Оплата» может отвечать за обработку платежей. Она взаимодействует с агрегатами, проверяя, что оплата корректна, и вызывая соответствующие доменные события.

7. Репозитории:

   • Репозиторий «Заказы» позволяет сохранять и извлекать заказы из базы данных. Например, когда клиент подтверждает покупку, система создает новый заказ и сохраняет его через этот репозиторий.

8. События домена:

   • Событие «Заказ создан» может инициировать процесс уведомления клиента и резервирования товара на складе.

Заключение

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