Однако, если ваше приложение имеет более 30 сценариев использования, ваша система подвержена движению в сторону Большого Комка Грязи (Big Ball of Mud). Если вы точно знаете что ваша система будет достаточно сложной, то вам следует рассмотреть возможность использования DDD для борьбы с этой сложностью. Другой пример ограниченного контекста — отправка уведомлений domain driven design что это через почту или смс. Это замкнутая область, которая пересекается с бизнес-моделью в четко определенных местах вызова функций отправки, и не использует модели из других областей. При моделировании проектирования ПО нужно держать бизнес domain/process в центре внимания, нежели структуры данных, потоки данных, технологию, внутренние и внешние зависимости.

Так как кодовая база у больших legacy-проектов со временем становится огромной, то в итоге вообще никто не понимает этих связей. Во-вторых, непонятно, где ждать Null Reference Exception. Потому что вы не знаете, заполнил ли предыдущий разработчик модель достаточно хорошо, или где-то остановился и вам надо вчитываться в код, или покрывать тестами, или еще что-то делать. Если вы знаете, что ваше приложение будет расти и, вероятно, часто изменяться, то DDD определеннопоможет вам в контроле сложности и реализации рефакторинга вашей модели с течением времени. Чтобы сервис корректно работал и выполнял все свои функции, между модулями системы нужно настроить связи.

Что такое Domain Driven Design?

Управление аэропортами, страховые распродажи, кафе, орбитальные полеты, вы его называете. Эту статью Архитектура Domain Driven Design for Services в которой приводится короткий пример. В статье приведено следующее миниатюрное описание Domain Driven Design.

А во-вторых, мы получаем от Event Sourcing легкое исправление ошибок. Например, кто-то ошибся и написал в коде минус вместо плюса. В обычном подходе, где мы пишем state и баланс в базу, мы бы устали вычищать эту ошибку. Нам бы пришлось поднимать первичные документы, высчитывать руками данные каждого человека, и потом только отображать. Мы храним не объект и не state нашего объекта целиком, а отдельные события, которые этот state меняют.

Domain Driven Design

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

• Так почему код должен быть на языке отличном от языка бизнеса?
• Адрес и время доставки с номером телефона не нужны ресторану, но у нас — общая модель заказа.
• Если у вас есть два Ивановых Алексея, то они будут двумя разными людьми, даже если у них совпадают поля.
• Для иллюстрации — схема интернет-магазина в таком представлении.
• У нас не такой перформанс, как в Badoo, например, где миллион событий может в один объект прилетать.

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

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

Базовая предпосылка структурировать все вокруг ваших сущностей и иметь сильную доменную модель. Создавая модель предметной области, разработчик не только проектирует архитектуру под текущие бизнес-процессы, но и создает возможности для последующего расширения. Если это будет возможно в предметной области, это будет возможно и в модели этой предметной области, а значит и в ПО. Основа — воссоздание предметной области в коде через бизнес-логику, взаимодействие объектов и соотнесение реальных условий применения продукта с реализацией. Ключевым понятием в DDD является «единый язык» (ubiquitous language). Ubiquitous language способствует прозрачному общению между участниками проекта.

Поэтому мы либо явно лочим нашу запись, используя pessimistic concurrency, либо используем optimistic concurrency, и тогда перед сохранением проверяем версию объекта. То есть мы сохраняем в базу и говорим, что апдейтим только объект с версией 4. Если вдруг в базе лежит уже 5 или 6 версия, мы падаем с exception optimistic concurrency (это мы так в коде реализовали), и цикл повторяется заново.

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

На рисунке мы видим описание бизнес-процессов в виде activity diagram, диаграмму классов для документов и диаграмму состояний документов, которые и реализуют бизнес-процесс. Но при этом все три модели — на едином языке и с прозрачной связью между ними. И принципы DDD говорят, что в коде информационной системы должны присутствовать те же самые объекты, а не какая-то другая реализация. DDD предлагает использоватьуниверсальный язык (UL) для описания всей логики бизнеса. На этапе анализа и проектирования,бизнес-правила и определения будут выражены на UL, который потом будет использоваться в реализации информационной системы.

Для того чтобы DDD можно было применить на практике в нашем проекте, мы должны фактически начать с нуля. Невозможно частично принять Domain Driven Design-концепцию, где остальная часть модели будет спроектирована традиционным способом. В этом случае удовлетворенность конечным продуктом будет низкой как со стороны IT-команды, так и со стороны конечного пользователя. Domain-driven design говорит же о том, что все это, конечно, важно, но бизнес и его потребности — главнее. Реальный бизнес — вот краеугольный камень любой системы и её архитектуры. Как правило первая итерация представляется собой минимально достаточное смысловое ядро — основной домен проекта и набор прикладной функциональности.

Какие трудности могут возникнуть при использовании Domain Driven Design подхода?

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

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