Domain Driven Design DDD что это такое? И как начать использовать DDD в разработке

DDD предоставляет инструменты и методы для разработки сложных программных систем, которые лучше соответствуют бизнес-требованиям и предметной области. Она способствует улучшению коммуникации между разработчиками и экспертами предметной области, а также повышению гибкости, масштабируемости и поддерживаемости системы. Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ. domain-driven design, DDD) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом. Таким образом, DDD сместил фокус от описания системы как черного ящика к описанию доменно ориентированный подход в разработке по внутреннего устройства, или системы прозрачного ящика.

Подведем итог: что дает клиенту и разработчику DDD

Но наш подход — это при использовании RabbitMQ позволить событиям приходить в разном порядке, в двойном избыточном размере и сделать так, чтобы для нас каждое событие было идемпотентным и коммутативным. Мы не смотрим на порядок и количество, а работаем, как есть. Это возможно достичь различными путями — использованием, например, correlation key. Сущности и Value Objects в Domain-Driven Design принято объединять в агрегат. При этом агрегат доступен извне как API вашего объекта. Например, есть какой-то объект, и с ним связан наш заказ, у которого есть модель адреса.

Как правильно работать с исключениями в DDD

Если вы производите какие-то изменения над Агрегатом, который содержит в себе Entity и Value Object, то либо все изменения проходят успешно либо все изменения не успешны. Такого случая, что что-то успешно а что-то нет не может быть. Aggregate (Агрегат) — группа сущностей, связанных одним корнем. Состоит из Entity и Value Object, как-бы является единым целым. Она также определяется по id и является границей транзакций при изменении данных (является границей уникальности для Entity).

Отделяем функциональные требования от бизнес требований.

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

Зачем нужен Domain-Driven Design

У нас тоже есть монолит, который мы начали писать много лет назад, и большая часть его логики реализована таким образом. Сервисы передают объекты друг другу, заполняя попутно какие-то поля или возвращая из себя новые объекты, но, тем не менее, эти объекты — дырявые. Мы привыкли начинать проект с базы данных, хотя она может стать одним из источников проблем для бизнес-приложения. Потому что бизнес растет, и вслед за ним повышается сложность системы. И самое плохое, что в итоге может произойти — все сущности переплетутся, даже если вы используете разделение по слоям. Правда, сейчас есть сложность с современной архитектурой, в которой системы реализуют активные сервисы, асинхронно взаимодействующие через очереди.

Как устроен Domain-Driven Design

Они помогают сделать код более поддерживаемым, модульным и расширяемым. Это не core domain, который в коде, некая сущность с основной логикой. DDD также обеспечивает основу для стратегического и тактического моделирования. Стратегическое проектирование позволяет точно определить наиболее важные области разработки на основе бизнес-ценностей.

• Это всё порождает связанность (coupling) и одновременно слабую кохезию (cohesion), то есть мы не понимаем без полного прочтения кода, что и как взаимосвязано в этой системе.
• Для планировщика, который работает внутри смартфона, это возможно.
• Это методология, которая применяется для получения высококачественной модели программного обеспечения, максимально точно отражающей поставленные бизнес-цели.
• Трогая какие-нибудь отчеты, вы совершенно неожиданно можете затронуть бэк-офис.
• DDD очень интересный и классный подход, как по мне лично, но он требует действительно много вложений от всей команды.
• Часто на крупных проектах складывается ситуация, когда каждый разработчик понимает только ту часть бизнес-логики, с которой ему непосредственно приходится работать, но не видит полной картины.

Задача менеджера в этой цепи обычно заключается в том, чтобы переводить с технического языка на «человеческий» и обратно. Поэтому стандартный подход к разработке сложного проекта требует больших усилий и концентрации внимания от всех участников. Это в свою очередь потребует открытого, здорового инепрерывного диалога, чтобы успешно перенести их терминологию в модель программного обеспечения. Подход DDD подразумевает, что каждому участнику проекта доступна полная и целостная информация о предметной области и бизнес-процессах. На начальном этапе при взаимодействии всех участвующих в проекте сторон разрабатывается модель предметной области. Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией.

Идея в том, чтобы установить адрес можно было только через сам заказ. Это всё порождает связанность (coupling) и одновременно слабую кохезию (cohesion), то есть мы не понимаем без полного прочтения кода, что и как взаимосвязано в этой системе. Так как кодовая база у больших legacy-проектов со временем становится огромной, то в итоге вообще никто не понимает этих связей.

DDD наиболее необходим для проектов с очень тяжелой бизнес логикой. Если попытаться сейчас объяснить вам в двух словах что же это такое — это подход проектирования, который нацелен на “упрощение сложного”. Однако, если ваше приложение имеет более 30 сценариев использования, ваша система подвержена движению в сторону Большого Комка Грязи (Big Ball of Mud).

Например, когда из приложения команды на запись попадают в одно приложение, а читаем мы из другого. С помощью CQRS мы разделяем команды на запись и запросы на чтение. И в этом случае мы можем эти две модели оптимизировать по очереди. Если у нас очень много чтения, то мы можем масштабировать модель Read — например, поставить рядом несколько серверов.

Supporting subdomain — важная составляющая, от которых зависит наш бизнес, но которые не имеют прямого отношения к Core domain. Если вы знаете, что ваше приложение будет расти и, вероятно, часто изменяться, то DDD определеннопоможет вам в контроле сложности и реализации рефакторинга вашей модели с течением времени. При работе над несколькими отдельными моделями в большой группе, различные члены команды могут не знать о сущностях других моделей, что усложняет процесс общей сборки конечного продукта. Такое разрастание функционала грозит образованием «больших комков грязи» — big balls of mud. Это крупные массивы запутанного, неряшливого кода, которые снижают производительность сервиса и осложняют его поддержку в будущем.

Репозитории — это такие сервисы, которые используют глобальный интерфейс, чтобы обеспечить доступ ко всем сущностям и ценностным объектам, находящимся в конкретной группе агрегатов. Например, можно считать команду «резать» репозиторием, когда она применяется к группе агрегатов «фрукты», которая включает агрегаты «яблоки», «груши», «бананы». Введение в Domain-Driven Design поможет вам понять основы этого подхода и применить его в вашем проекте, чтобы создать гибкое и эффективное программное обеспечение. Также получился более выразительный код, по нему легко отследить что же происходит с событиями в домене (мы вначале делаем что-то с доменом, а потом уже в репозиториях реагируем на это и как-то изменяем данные).

IT курсы онлайн от лучших специалистов в своей отросли https://deveducation.com/ here.