Большинство новых понятий не выдерживают проверку временем и быстро выходят из обихода. Если не хочешь переписывать модель данных раз в полгода, то опирайся на устоявшиеся, надежные и всем понятные термины. В DDD-разработке принципом выделения микросервиса в отдельное приложение будет служить ограниченный контекст. Это не отменяет технический принцип разделения сервисов (если это обусловлено необходимостью обеспечения высокой производительности).
Но контекстный принцип будет доминирующим и обязательным. Унифицированный язык принадлежит к ограниченному контексту. Домен приведенной выше документации — ‘Система авторизации’.
Domain Driven Design — DDD-программирование
В данном примере класса, объект задачи описывает свойство модели, которое является абстрактным и может быть использовано в разных контекстах. Например, это может быть задача по программному обеспечению или задача по уборке дома. Также класс содержит множество функций, которые образуют поведение модели и свойства, которые описывают состояние. В DDD используется паттерн объектной модели (POCO), который позволяет создавать объекты бизнес-модели без привязки к конкретной платформы или технологии. Это позволяет возможность переносить объекты модели на другую платформу и использовать их повторно в разных системах. Поэтому агрегат важно сохранять в транзакциях, потому что он является хранителем целостности, инварианта объекта.
Такая реализация ограничивает первую итерацию решением только основной задачи, но позволяет начать использование продукта намного раньше по сравнению с реализацией всего и сразу. Её главным компонентом является смысловое ядро — Core domain — часть домена, имеющая первостепенное значение для выполнения главной задачи. Проблемы, которые решают разрабатываемые продукты, могут быть в разных предметных областях, не обязательно знакомых программисту. Другими словами, программист должен до некоторого уровня стать экспертом в предметной области. В зависимости от соотношения контекстов, могут быть различные способы сопряжения. Может быть выделено общее ядро, или периферийная часть, описывающая только передаваемую информацию в шаблоне поставщик — заказчик, а может быть использован общедоступный язык.
Единый язык
Например, вместо того чтобы делать команду «нарезать яблоко» и повторять её n раз, можно все яблоки объединить в группу «яблоки» и применить к этой группе команду «нарезать». Однако, если ваше приложение имеет более 30 сценариев использования, ваша система подвержена движению в сторону Большого Комка Грязи (Big Ball of Mud). Если вы точно знаете что ваша система будет достаточно https://deveducation.com/ сложной, то вам следует рассмотреть возможность использования DDD для борьбы с этой сложностью. С распространением DDD, появились новые методы улучшающие и упрощающие процесс создания единого языка (Ubiquitous Language). Самый важный и наиболее часто используемый метод это Событийный штурм (Event Storming). С помощью Domain-Driven Design мы структурировали сервис для СФУ.
Но эта магия оказывалась вовсе не такой, на которую рассчитывал бизнес. Этот класс не является частью бизнес-модели, но он отражает и обслуживает работу с задачей в контексте системы. Класс позволяет добавлять, изменять и выгружать данные задач из постоянного хранилища данных. Использование нескольких моделей на различных уровнях проекта. Данный подход используется для уменьшения различных связей между моделями, что исключает сложность и запутанность кода.
TDD, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development
Также не стоит объединять несколько сущностей в одну, более удобную с программной точки зрения. Если с точки зрения бизнеса две сущности могут иметь разные свойства, то и в базе данных им нужны, как минимум, две разные таблицы. Классический пример применения MDD, который используется уже давно, — моделирование баз данных. На основе одной концептуальной модели данных вы можете поддерживать несколько связанных с ней физических моделей для различных СУБД. Диаграммы выступают в качестве своеобразных «чертежей», из которых различные автоматизированные и полуавтоматизированные процессы извлекают программы и соответствующие модели. Причем автоматическая генерация кода варьируется от извлечения простого скелета приложения до получения конечной кодовой базы (что сравнимо с традиционной компиляцией).
- Идея UML как средства описания устройства софта, позволяющего создавать его без разработчиков, провалилась, так UML не работает.
- Как правило, в подходе DDD всегда должно быть место для доменного эксперта, который обладает глубокими знаниями о подходе и будет самостоятельно выступать в качестве «компилятора» в коммуникации бизнеса и IТ.
- Мы не можем создать программный продукт, который охватит всю предметную область.
- Анемичные модели говорят о том, что у объекта нет бизнес-логики, то есть это такая DTO, которая содержит только данные.
В обычном подходе, где мы пишем state и баланс в базу, мы бы устали вычищать эту ошибку. Нам бы пришлось поднимать первичные документы, высчитывать руками данные каждого человека, и потом только отображать. Мы храним не объект и не state нашего объекта целиком, а отдельные события, которые этот state меняют. Очень явно можно увидеть этот подход в бухгалтерском учете.
CQRS и Event Sourcing
Сложное практически всегда состоит из простых частей, соединенных простыми связями. Благодаря применению Domain-Driven Design код веб-сервиса или мобильного приложения получается несложным и понятным. В итоге упрощается его чтение, а значит — поддержка и развитие сервиса в будущем.
Во-вторых, непонятно, где ждать Null Reference Exception. Потому что вы не знаете, заполнил ли предыдущий разработчик модель достаточно хорошо, или где-то остановился и вам надо вчитываться в код, или покрывать тестами, или еще что-то делать. Если вы знаете, что ваше приложение будет расти и, вероятно, часто domain driven design что это изменяться, то DDD определенно
поможет вам в контроле сложности и реализации рефакторинга вашей модели с течением времени. Если в вашем приложении реализует менее 30 сценариев использования (Use Cases), может вам проще использовать фреймворки Symfony или Laravel, для управления всей бизнес логикой.
Domain Driven Design (сокращенное название DDD) — что это за подход?
Это всё сыпется непрерывным потоком в какое-то append-only хранилище. Зачастую это даже не реляционная база данных, а что-то оптимизированное под запись, например, Kafka. Она позволяет писать большое количество событий и очень хорошо с этим справляется. Таким образом мы меняем баланс, но этот баланс только внутренняя переменная в памяти. Мы нигде никогда не храним баланс как число, а просто каждый раз его рассчитываем. Да, по перформансу это не очень эффективно, но позволяет, во-первых, легко реагировать на ошибки.
При работе над несколькими отдельными моделями в большой группе, различные члены команды могут не знать о сущностях других моделей, что усложняет процесс общей сборки конечного продукта. Когда над проектом работает большое количество людей, то есть тенденция дробить модель на несколько более мелких фрагментов. Чем больше людей, тем более значительна данная проблема. Репозитории — это такие сервисы, которые используют глобальный интерфейс, чтобы обеспечить доступ ко всем сущностям и ценностным объектам, находящимся в конкретной группе агрегатов. Например, можно считать команду «резать» репозиторием, когда она применяется к группе агрегатов «фрукты», которая включает агрегаты «яблоки», «груши», «бананы».