Содержание
Так появился термин Data Driven Decision, который подразумевает использование фактических данных для принятия управленческих решений. Понимать важность доменных событий и возможность их использования при интеграции с другими Bounded Contexts. DDD позволяет существенно увеличить скорость разработки, снизить стоимость сопровождения и повысить качестве программного обеспечения. Но, несмотря на это, внедрение DDD на практике сталкивается с множеством трудностей и препятствий, что нередко приводит к полному отказу от применения данного похода в проекте. Доклад прошел хорошо, слушателей набрался практически полный зал. Единственная проблема была в том, что я чуть-чуть не влез в 45 минут, но поскольку после моего доклады был обед, то я имел возможность рассказать доклад до конца.
Строить такие объекты тяжело, и в DDD прижилась идея склеить Event Sourcing и CQRS. В Domain-Driven Design это называется стратегическим дизайном или стратегическими паттернами. Но сегодня я хотел бы быть чуть ближе к коду, и поговорить о тактическом дизайне. Сервисы — это функции, которые не привязаны к сущностям или ценностным объектам. С распространением DDD, появились новые методы улучшающие и упрощающие процесс создания единого языка . Самый важный и наиболее часто используемый метод это Событийный штурм .
Именно поэтому важно уделять внимание терминам, которые используются в данной сфере. Это обеспечивается постоянным общением двух сторон — разработчиков приложения и клиентов. Такой подход отражает главный принцип DDD — разработка не должна быть в отрыве от бизнес-задач.
Очень понравился тренер Максим Кичук, который рассказывал о наглядных примерах из своего опыта работы. Понравилось, что помимо теории есть практика, которая потом обсуждается с тренером. У курса хорошие структурирование материала и практические задания на применение Event Sourcing. Принципы объектно-ориентированного проектирования и программирования. За ней скрывается, например, Session от NHibernate или просто TransactionScope. Если говорить про MVC, то управление транзакцией осуществляется на уровне контроллеров объектом UnitOfWork, у меня в блоге про это было много примеров.
Для чего не стоит использовать DDD?
Одним из наиболее эффективных средств борьбы с растущей сложностью является методология проектирования на основе модели предметной области . Тогда не поможет, мы боремся не с многопоточностью, а с тем что у системы может быть много пользователей. Например, это корпоративная CRM или веб-сайт, и возникает ситуация, когда два объекта представляют одну и ту же сущность, но при этом не подозревают друг о друге. КОгда же работа идет на уровне данных, при одновременности операций включается в работу механизм блокировок, атк что данные в транзакции не могут получиться несогласованными.
DDD совсем не стоит использовать для слишком маленьких и простых проектов, например одностраничный магазин. Его основная задача — совместить эти модели в процессе разработки/доработки. Последняя глава этой части посвящена технике Event Storming, которая является групповой техникой моделирования для упрощения процесса получения знаний о домене и формировании ubiquitous language. Интересно, что цвета шагов совпадают с рекомендованными цветами стикеров для карточек, которые в основном используются на каждом шаге. Отдельная глава посвящена тому, как правильно выстроить взаимодействие между командами, отвечающими за разные bounded contexts. Вариантов несколько и они представлены на рисунке ниже.
Но модель к вам уже пришла целиком, а вы не использовали ее в полную силу. Мы привыкли начинать проект с базы данных, хотя она может стать одним из источников проблем для бизнес-приложения. Потому что бизнес растет, и вслед за ним повышается сложность системы. Появляются новые приложения, их становится всё больше. И самое плохое, что в итоге может произойти — все сущности переплетутся, даже если вы используете разделение по слоям.
По языкам и технологиям
Не скажу что это хорошо, но лучше чем не использовать вообще, на мой взгляд. DTO — класс, не содержащий логики, для передачи информации между слоями нашего приложения. Используются для того чтобы типизировать какой-то набор данных. Мне кажется это наиболее частая проблема, с которой лично я сталкивался на проектах.
Если вы производите какие-то изменения над Агрегатом, который содержит в себе Entity и Value Object, то либо все изменения проходят успешно либо все изменения не успешны. Такого случая, что что-то успешно а что-то нет не может быть. Aggregate (Агрегат) — группа сущностей, связанных одним корнем.
- И в данном случае оно равнозначно применению ActiveRecord.
- Занимается разработкой ПО в финансовой области с использованием стека технологий .Net.
- Создаем удобные и эффективные сайты, которые нравятся пользователям и хорошо продвигаются в поисковых системах.
- Write-модель — это те события, которые падают из приложения.
Использование служб позволяет ввести многослойную архитектуру, так же интегрировать несколько моделей, что вносит зависимость от инфраструктуры. Вам потребуется участие экспертов предметной области. Это в свою очередь потребует открытого, здорового и непрерывного диалога, чтобы успешно перенести их терминологию в модель программного обеспечения. Вдобавок ко всему, вам придется приложить усилия, чтобы избежать технических моментов реализации на начальном этапе, а сосредоточиться в первую очередь о поведении объектов и создании единого языка . Ограниченный Контекст — ключевой инструмент DDD, это явная граница, внутри которой существует модель предметной области. Она отображает единый язык в модель программного обеспечения.
Связь DDD с волосами на лице
Если вдруг в базе лежит уже 5 или 6 версия, мы падаем с exception optimistic concurrency (это мы так в коде реализовали), и цикл повторяется заново. Из Read модели вычитываем агрегат, мержим его с новым событием по какой-то бизнес-логике, откидываем старое, делая дедупликацию и соблюдая идемпотентность, а потом сохраняем агрегат обратно. https://deveducation.com/ Таким образом мы меняем баланс, но этот баланс только внутренняя переменная в памяти. Мы нигде никогда не храним баланс как число, а просто каждый раз его рассчитываем. Да, по перформансу это не очень эффективно, но позволяет, во-первых, легко реагировать на ошибки. Мы видим всю историю, можем в любой момент понять, что пошло не так.
И, наоборот, когда мы говорим про заказ в контексте доставки, нам не важно, сколько грамм теста и сыра мы списали на заказ. Во-вторых, непонятно, где ждать Null Reference Exception. Потому что вы не знаете, заполнил ли предыдущий разработчик модель достаточно хорошо, или где-то остановился и вам надо вчитываться в код, или покрывать тестами, или еще что-то делать.
Визуализация Big Data
Более того, на разных этапах развития вашего приложения они могут плавать, и это нормально. Например, если Bounded Context в вашей CRM связан с продажами, то со временем его можно разделить на продажи и маркетинг. Другая большая проблема такого подхода — это универсальные модели. Во-первых, каждый раз вы используете только ее часть. Вы, конечно, можете выбрать только те поля, которые нужны в application-сервисе.
Чтобы сервис корректно работал и выполнял все свои функции, между модулями системы нужно настроить связи. С помощью Domain-Driven Design мы структурировали сервис для СФУ. Выделили главный домен — прием документов от абитуриентов из разных городов. ddd что это Ubiquitous Language — язык описания или универсальный язык. Он нужен, чтобы описание домена и моделей было однозначным, не возникало противоречий. Данные — это, конечно, хорошо, но они никогда не скажут вам, в чём именно проблема и как её решить.
Подведем итог: что дает клиенту и разработчику DDD
Таким образом обеспечивается соответствие поведения готовой системы потребностям заказчика, без чего сложные IT-проекты едва ли могут стать успешными. Также не стоит объединять несколько сущностей в одну, более удобную с программной точки зрения. Если с точки зрения бизнеса две сущности могут иметь разные свойства, то и в базе данных им нужны, как минимум, две разные таблицы. Рано или поздно мы успеваем между изменениями сохранить.
Модуль 3. Стратегическое проектирование.
Он предоставляет нам инструменты стратегического и тактического моделирования для разработки высококачественного программного обеспечения, соответствующего нашим бизнес-целям. Маркетинг на основе данных − это итеративный процесс, который постоянно развивается и расширяется. В грамотно выстроенном маркетинге процесс анализа и интерпретации данных ведется постоянно. Нельзя оперировать данными пятилетней давности для работы с современной аудиторией сайта.
На других языках
Google активно внедряет Data Driven, например, вы можете использовать атрибуцию на основе данных при запуске контекстной рекламы в Google AdWords. Да, это правда, что команда в Google не могла выбрать между двумя вариантами синего, поэтому они тестируют 41 оттенок, чтобы увидеть, какой из них лучше работает. Недавно у меня была дискуссия о том, должна ли граница быть шириной 3, 4 или 5 пикселей, и меня попросили доказать свою правоту. Я уже устал обсуждать такие незначительные дизайнерские решения. В этом мире есть более захватывающие проблемы дизайна, которые требуют решения. Если в традиционном «ручном» подсчете используется небольшое количество данных, то может возникнуть дискуссия относительно репрезентативности построенных на основе этих данных графиков и диаграмм.
Leave a Reply