Комментарии 28
А при создании скольких приложений с применением DDD вы участвовали в качестве разработчика?
Вроде из начала статьи видно что DDD должна решать некоторые проблемы, но почитав дальше понимаешь что проблемы перетекли в другую плоскость и просто стали другими.
Надо поискать уже готовый код с ДДД чтоб лучше понимать что и как, а то из статьи я бонусов не заметил, похоже на то как ФП рекламировали, насколько оно хорошее и решает кучи проблем. На практике всё точно также, проблемы стали просто другими и выросла сложность.
Авторы DDD и люди развивающие этот подход говорят, что они чаще всего слышат просьбу показать код или пример приложения, написанного в соответсвии с методологией. Это говорит о том, что те кто просят не понимают или не знакомы с DDD.
DDD не накладывает никаких технических ограничений, не навязывает использование шаблонов или подходов. Так же вы не найдете там правил построения архитектуры, организации кода, структурирования файлов, классов и т.д. Код - это только маленькая, самая последняя часть процесса. Конечно, невозможно в одной статье описать методологию хоть сколько нибудь внятно.
Люди развивающие подход имеют кучи готовых примеров с обьяснениями почему они именно так сделали, а просто теоритическое описание не говорит о плюсах и минусах вообще ничего. Это всё равно что смотреть рекламу и верить каждому слову. С примерами всё намного веселее ведь могут найтись эксперты в области и обьяснить как на само деле лучше и какие проблемы возникают при том или ином подходе.
Вообщем мне совершенно не понятно почему при других архитектурных решениях можно предоставить примеры решений в виде кода для оценки обществом, а тут это не стоит делать.
почему при других архитектурных решениях...
Потому что DDD это не архитектурное решение.
Вы можете взглянуть на два примера приложений, сделанных в соответствии с DDD и не найти в них ровным счетом ничего общего. Советую вам ознакомиться с литературой. Могу посоветовать "Patterns, Principles, and Practices of Domain-Driven Design" by Scott Millett, Nick Tune
Если следовать одним и тем же правилам и цели одинаковые то не может получиться 2 очень разных решения. А книжка довольно абстрактная, а те примеры которые есть тоже довольно простые. И единственное полезное что там нашёл это "What it does insist on, though, is that the complexity of your domain model is kept isolated from the complexities of your technical code. Any architecture that supports this is a good fit for DDD" :D
Абсолютно с вами согласен! Не буду углубляться в терминологию, расскажу как я понимаю DDD.
Когда разработчик открывает исходный код, ему должны бросаться в глаза сущности, вокруг которых идет разработка приложения:
если это магазин - то должна быть карточка товара, пользователь, расчет;
если это парикмахерская - то запись, мастера, и т.д.
То есть, функционал ограниченный конкретной областью. Абсолютно противоположный вариант, это общие названия папок, в которых собраны все сущности сразу (actions, components и т.д.). Это был пример простыми словами. Я участвовал в 5-ти проектах на разных работах, где научился DDD пропустив через себя, и с удовольствием применяю.
Теперь ближе к практике. Putout - линтер, который пишется по DDD. Его структура очень проста, и в то же время конкретна.
Есть движки:
Парсер (строка -> AST, AST -> строка)
Загрузчик (загружает плагины)
Исполнитель (исполняет плагины)
Процессор (загружает линтеры разных типов файлов, а так же достает JavaScript и прогоняет через предыдущие 3)
Движок Процессор поддерживает следующие процессоры:
markdown
json
yaml
gitignore
и так далее
А еще есть плагины и форматтеры. Вот и все DDD. Главное помнить, что сущности должны быть разделены на конкретные области, лежать в конкретных местах не покидая их пределов, и не размазываясь по всем папкам сразу. Таким образом обеспечивается low in coupling and high in cohesion, то есть упрощается поддержка приложения.
Ну и конечно, общаться с представителями бизнеса стает проще, ведь все говорят на одном языке.
С примерами всё намного веселее ведь могут найтись эксперты в области и обьяснить как на само деле лучше и какие проблемы возникают при том или ином подходе.
Соглашусь, что с примерами разговор идет конструктивнее.
Вот мой домашний проект, с архитектурой в сторону DDD, а именно (что считаю важным в таком подходе):
Модуль независимо выполняет свою часть работы, и не завязан на внешние зависимости
Имеет независимый неймспейс
Модели соответствуют бизнес-сущностям. И работа с ними происходит именно как с бизнес-сущностями, а не как с классами с набором данных
Нет работы с базой данных. Получили на вход данные, обработали, вернули ответ - все, на этом задача DDD-модели закончилась (по моему убеждению)
Да, и самое главное - DDD модель должна спокойно выполнять свою задачу без всяких фреймворков. На мой взгляд это и основная задача - отделить бизнес-логику (где нас интересует только бизнес логика) от логики фреймворка, работы с базами, кешем и прочим.
Вот пачка референсов https://github.com/heynickc/awesome-ddd#sample-projects
как ФП рекламировали, насколько оно хорошее и решает кучи проблемТак ведь правда, причем примеров использования намного больше, чем у DDD.
У обоих, кстати, высокий порог вхождения, почему они не смогут стать индустриальным стандартом.
Вроде из начала статьи видно что DDD должна решать некоторые проблемы,
но почитав дальше понимаешь что проблемы перетекли в другую плоскость и
просто стали другими.
Это потому, что автор начал писать о DDD, но потом сменил тему и начал писать о том, что к DDD никакого отношения не имеет.
Как-то уж больно на микросервисы похоже - когда domain и есть отдельный микросервис
В общем случае домен != контекст != микросервис. Есть отличная статья на эту тему https://vladikk.com/2018/01/21/bounded-contexts-vs-microservices/
Мнение понятно отчего при разговоре о DDD всплывает постоянно Event Sourcing? Когда речь заходит про event sourcing нужно всегда уточнять, что правильно его реализовать очень сложно и дорого. Потому что все должно быть 100% детерминированно.
У вас где-то concurrent ordered map, скорее всего там skip list и рандом внутри. А значит порядок обхода этой коллекции будет разным при каждом запуске.
DateTime.Now, очевидно.
Настройки системы, например дефолтный часовой пояс.
Настройки самой программы. Типа размер кеша.
Можно поискать в блоге LMAX рассказы о том, как они решают эти проблемы. Это долго, дорого и больно. Не надо event sourcing если у вас не high load и не сложная in-memory модель (обычно это из-за требований к latency) короче если вы не делаете биржу или мультиплеер в реальном времени это не ваше.
Это один из возможных способов декомпозиции приложений. Некое здравое зерно есть и тут.
Но в чистом виде обычно такие методологии всегда приходится применять с поправкой на реальность. Сразу скажу, что у большинства ИС есть довольно значительная доля того, что называется "общие справочники". Это справочники клиентов, классификаторы товаров и тому подобные вещи. Попытка их разделить или дублировать чаще всего не имеет никакого смысла. Если ваше приложение всё-таки может обойтись без доступа к общим справочникам, то тут как раз редкий случай, когда микросервис будет наиболее простым решением. Особенно большое зло -это простое дублирование общих справочников.
Ещё меня настораживает подход, когда вместо потока коротких транзакции применяется очередь сообщений. Во всяком случае такой подход должен иметь очень серьезные основания.
И, наконец, если учесть, что самое дешёвое в проектировании и эксплуатации место бизнес-логики это как раз back end, и мы понимаем все требования, которые не позволяют поступать именно так, то некое деление системы на отдельные части можно произвести тем или иным способом.
Хорошая статья, спасибо
Но "кохезия"!!.. Кохезия это сильно:)
Low coupling, high cohesion - низкая связанность [модулей], высокая связность [внутри модуля]
Лично я сходу не отличаю связанность от связности, особенно на слух. Поэтому использую термины каплинг и кахезия, чтобы было очевиднее и даже просто не оговориться.
Правда еще есть когезия, может этот термин форсить?)
Дидактически интересный подход к изложению известного материала. Спасибо. Полезно.
Как устроен Domain-Driven Design