Area Driven Design: Что Это Такое И Как Его Использовать

Так как код мы исправили, то и отображаемое состояние объекта тоже становится правильным. Представим, что мы написали свой Фейсбук, и там каждый пост — это агрегат, а лайк  — часть этого агрегата. При каждом лайке нам пришлось бы перезаписывать нашу модель.

Подход К Проектированию По Ddd

Из Learn модели вычитываем агрегат, мержим его с новым событием по какой-то бизнес-логике, откидываем старое, делая дедупликацию и соблюдая идемпотентность, а потом сохраняем агрегат обратно. У нас работает код консьюмера, который подписан на какое-то брокер-сообщение — на топик Kafka или на очередь в RabbitMQ. На запрос какого счета  обычном подходе мы просто вычитываем его баланс и отдаем наружу. В подходе Occasion Sourcing мы вычитываем не баланс, а эвенты. То есть мы подаем какие-то эвенты на вход и реализуем код, который эти эвенты перепроигрывает на голом объекте. Есть несколько подходов, которые позволяют с этим бороться.

Здесь описываем те интерфейсы, которые будут помогать работать с моделями нашего домена. Они могут обращаться к репозиториям и другим сервисам и будут выносить всю логику из контроллеров. Ниже на картинке мы видим, что у нас есть класс Order с полями Id, OrderDate, BuyerId, Address Регрессионное тестирование, OrderItems (где последние три будут являтся Value Object).

Рассказываем, что такое Domain-Driven Design — предметно-ориентированное проектирование. DDD — это набор подходов для перенесения знаний о домене в код. Мне кажется это наиболее частая проблема, с которой лично https://deveducation.com/ я сталкивался на проектах. Вообще модель системы не соответствует представлению о системе у бизнеса.

Для этого используется такое понятие как Ubiquitous Language — “единый язык”. Supporting subdomain — важная составляющая, от которых зависит наш бизнес, но которые не имеют прямого отношения к Core domain. А пока будем считать, что ограниченный контекст — это граница вокруг системы. Вместо этого все дело в понимании проблемы, которую вы должны решить в контексте бизнеса. Domain-driven design говорит же о том, что все это, конечно, важно, но бизнес и его потребности — главнее. Реальный бизнес — вот краеугольный камень любой системы и её архитектуры.

Ограниченный Контекст

Преимущество такого проектирования в том, что модель разрабатываемой IT-системы сразу базируется на сущностях и процессах предметной области, и у исполнителя и заказчика формируется одинаковое ви́дение системы. А выделение смыслового ядра позволяет команде правильно расставить приоритеты, сосредоточившись в первую очередь на самой важной для бизнеса задаче. Домен — область знаний/деятельности, для которой разрабатывается приложение. Ясно, что для юристов есть свои термины и важные понятия, которые отличаются от слов, используемых в нефтегазовой промышленности. Причем это не просто слова, они отражают важные для заказчика процессы, связи. Именно поэтому важно уделять внимание терминам, которые используются в данной сфере.

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

• Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией.
• ● Единый язык — разработчики, менеджеры, аналитики и другие участники процесса вырабатывают на встречах список ключевых терминов и придерживаются их во всех процессах.
• Причем если первый раз оно нормально замержилось, то во второй раз всё может пойти по-другому, потому что состояние поменялось, и может быть, его уже нельзя мержить.
• DDD решает проблему сложности, разбивая домен на управляемые части с использованием ограниченных контекстов, определяя четкие обязанности и взаимодействие между различными частями системы.

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

У тебя не просто какие-то логи, а прямо конструкция принцип ddd твоего кода. Заметим, что чтение и запись данных могут сильно отличаться в различных приложениях. Например, в социальных сетях люди больше читают, чем пишут.

Write-модель — это те события, которые падают из приложения. Баланс пополнили, осуществился перевод, сняли деньги, клиент получил штраф, оплатил комиссию, еще что-то. Это всё сыпется непрерывным потоком в какое-то append-only хранилище. Зачастую это даже не реляционная база данных, а что-то оптимизированное под запись, например, Kafka. Она позволяет писать большое количество событий и очень хорошо с этим справляется. Таким образом мы меняем баланс, но этот баланс только внутренняя переменная в памяти.

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

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

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

Это крупные массивы запутанного, неряшливого кода, которые снижают производительность сервиса и осложняют его поддержку в будущем.