Рано или поздно сеть моргнет, своя БД станет недоступна доменно ориентированный подход в разработке по на какое-то время, и мы получим несогласованное состояние. Если у вас есть два Ивановых Алексея, то они будут двумя разными людьми, даже если у них совпадают поля. Value Object — например, деньги — может содержать валюты и amount. И если эти два поля совпадают, вы считаете, что это одинаковые вещи. Например, когда мы говорим с бухгалтером, он понимает про заказ пиццы какие-то свои вещи, и не надо его грузить временем или адресом доставки.

Поваренная книга разработчика: DDD-рецепты (5-я часть, Процессы)

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

Функциональные и нефункциональные требования

Для определения границ объекта нам могут помочь данные — не сами по себе, а их источник. Если данные приходят из двух разных источников, то, скорее всего, здесь два Bounded Context, две модели. Как только мы повезли заказ куда-то, он сразу становится другой моделью.

Рекомендации по внедрению Domain-Driven Design

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

Важно понимать, что DDD не говорит, как писать код, то есть не исключает ни одну из практик, или принципов разработки, таких как SOLID, KISS и так далее.

Основные инструменты Domain-Driven Design

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

Учимся проектировать на основе предметной области (DDD: Domain Driven Design)

Репозитории и сервисы могут быть реализованы в различных технологиях, таких как базы данных, ORM-фреймворки или API. Теперь, перейдем к стратегическому проектированию, где ключевыми концепциями являются поддомены и Bounded Contexts. Профессиональная конференция для Python-разработчиков пройдет 27 и 28 сентября в Москве. Расписание уже готово, выбрать самые интересные доклады можно уже сегодня. И наконец, Domain-Driven Design и всего его тактические паттерны позволяют сделать рост стоимости не уходящим в потолок при создании новой фичи, а растущим постепенно. От роста стоимости вы совсем не избавитесь, потому что у вас появляются консьюмеры, связанность по коду и бизнес-логике.

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

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

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

Очень явно можно увидеть этот подход в бухгалтерском учете. Мы работаем в режиме append-only и получаем от этого кучу бенефитов. Во-первых, мы видим не только конечный state, но и как мы к этому state пришли.

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

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

Например, вместо того чтобы делать команду «нарезать яблоко» и повторять её n раз, можно все яблоки объединить в группу «яблоки» и применить к этой группе команду «нарезать». Domain driven design (DDD) — подход к разработке приложений, основанный на выделении доменов (domain). В моей следующей статье сущности и объекты-значения с некоторыми примерами кодов. Чтобы понять, как работает бизнес, вам нужно принять участие в некоторых дискуссиях с вашей командой. Это дает вам глубокое понимание бизнес-целей и позволяет эффективно выполнять обнаружение программного обеспечения.

И, наоборот, когда мы говорим про заказ в контексте доставки, нам не важно, сколько грамм теста и сыра мы списали на заказ. Решением будет разделить заказ на три части, так мы избавимся от мусорных полей. Конечно, у нас будут сквозные поля — ID, сумма, например. Но при этом поля, специфичные для одной области знания, не будут засорять другие. Но даже если разработчики все хорошо заполнили, всё равно непонятно, сколько лишних аллокаций памяти мы сделали для того, чтобы этот объект у нас появился в приложении.

Либо мы оптимизированы под быстрое чтение, но долго записываем. Какие-то storage решают эту задачу успешнее, какие-то менее успешно. Есть несколько подходов, которые позволяют с этим бороться. RabbitMQ частично умеет делать редупликацию и reordering.

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

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