Comments 40
"DDD – это микросервисная архитектура на базе сущностей предметной области. "
Разве DDD относится только к микросервисам?) вроде как смысл в логическом разделении данных
Вероятно, каждый понимает её по своему, но если почитать синюю и красную книги, то там речь идет именно о системах/микросервисах, скрывающихся под ограниченными контекстами. Более того, в книгах огромные разделы посвящены именно построению микросервисов на основе DDD
Увы нет на руках этих книг, но даже нас в университете учили, что DDD про разделение на предметные области. Микросервис - частное такого деления. Но с другой стороны я согласен, что в большинстве речь про микросервисы. Не знаю какие сходу доказательства могу привести, но даже в [документации .NET](https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice) такая строчка: "each Bounded Context correlates to a microservice", то есть соответствует, а не является
Если попробовать применить DDD на практике, то становится понятным, что само понятие домена - чисто информационная вещь, которую особо никак не используешь. В реальности очень многие сущности предметной области (ограниченные контексты) могут входить (и входят) сразу в несколько доменов. А если сделать следующий шаг и подумать над ПРАКТИЧЕСКОЙ целью DDD, то становится очевидным, что концепция создавалась в первую очередь для упрощения микросервисной архитектуры
Есть хороший разбор книг Эванса и Вернона в трёх частях https://vaadin.com/blog/ddd-part-1-strategic-domain-driven-design.
Первая часть посвящена стратегическому уровню DDD, который концентрируются на проблемах бизнеса: доменах, под-доменах и их классификации. Для каждой проблемы обозначаются границы её решения, i.e. bounded context. Это то место, внутри которого будет жить реализация. Здесь же способы интеграции между отдельными решениями, исходя из проблематики бизнеса.
Во второй части описыватся тактический DDD, с фокусом на моделировании: entities, aggregates, domain events - все что вы любите.
В третьей части он показывает как можно вписать такую модель в приложение, на примере Hexagonal Architecture. Здесь модель получает конкретную реализацию и обрастает снаружи технической обвязкой: api, UI, базами данных и т.п.
Микросервисы это просто один из паттернов реализации приложения, построенный на идеях компонентной архитектуры. Есть и другие. Например вы можете завернуть их в приложение для десктопа или телефона, сделав ближе к пользователю. Или монолита - упростив развертывание. Или ... Все будет зависеть от остальных требований.
А что у вас за университет был? В моём такого не было, а хотелось бы.
посвящены именно построению микросервисов на основе DDD
Вот именно что на основе. DDD сам по себе совершенно не связан с микросервисами.
Далее, разбиение проектируемой системы на всё более мелкие и простые части - основа вообще любого метода проектирования, и DDD или микросервисы тут вообще не могут претендовать на уникальность.
Далее, многое в DDD является просто стандартом де факто в любом объектно-ориентированном подходе, где классы соответствуют сущностям домена, а их методы - действиям над сущностями. Это стандарт с начала 90-х, так что ничего нового.
Далее, если заменить слово "микросервис" (точнее, "ограниченный контекст") на "модуль" или "подсистема", то все преимущества будут те же для любого монолита. Более того, монолиты требуют меньше ресурсов, так как избегают дуплицирования многих нижних уровней.
Итого - все описанные в статье принципы и плюсы полностью применимы к монолитам и любым другим вариантам системы/продукта.
Кстати, слово "система" никуда не девается в варианте микросервисов.
Вот именно что на основе. DDD сам по себе совершенно не связан с микросервисами.
Главное, чтобы это не было т.н. "ложным убеждением". На основании чего Вы это утверждаете?
Просто попробуйте представить, что ситуация может быть как раз обратной.
Все остальные доводы в ответе следуют из первого утверждения, как я понимаю.
Единый язык в этом контексте обозначает, что Микросервис = Сущность предметной области, и не более.
может быть все-таки не сущность, а ограниченный контекст?
А есть разница?
в одном ограниченном контексте может быть много сущностей
и какой отсюда вывод? Что такое, на Ваш взгляд, ограниченный контекст?
Ну как я понимаю, Счет и Начисления счета - это грубо говоря, ограниченный контекст, а сущности - Счет и Начисление.
Вы предлагаете уж совсем мелкое деление. Счет - в отдельном МС, Начисление - в отдельном МС. А они не существуют и не могут существовать друг без друга, и обработка их должна вестись в одной функции.
Каких именно сущностей и почему много? В этом весь вопрос. И не превратится ли это "много" в очередную монструозную систему на базе кубера, как это, в основном, и происходит?
DDD – это микросервисная архитектура на базе сущностей предметной области.
Горшочек, не вари. Хватит уже микросервисов. Уже и к DDD их приплели.
DDD без микросервисов - возможны. Микросервисы без DDD - тоже. Ортогональные подходы абсолютно.
У Вас отрицательный опыт работы с микросервисами? Что с ними не так и почему DDD не надо лепить к микросервисам?
Да потому что DDD можно применять там, где в итоге невозможны микросервисы, что ставит под вопрос их безоговорочную привязку. Ещё потому что DDD это про очерчивание сущностей по бизнес-требованиям, и есть разные подходы к этому даже в general-purpose языках. Способ взаимодействия модулей (монолит/микро/макро/хоть что) тут вообще ни при чём. Эти подходы можно успешно объединить, да, но нельзя сказать, что они по умолчанию связаны.
Если это воспринимать как метафору, т.е. "DDD - это как микросервисная архитектура, но для наших ментальных моделей, отражаемых в коде, а не для самого кода и его технологической обвязки", то это довольно удачная метафора, не описывает все DDD, но указывает на ключевые вещи. Но у вас в статье получилось слишком буквальное сравнение, что понятно - вы старались донести действительно удачную метафору. Все возражения как мне кажется по поводу этой буквальности. Но для начала обсуждения неплохо. Скажем вы пишете в ответе на другой коммент: "И не превратится ли это "много" в очередную монструозную систему на базе кубера?" - хороший вопрос! Но бывают действительно сложные предметные области, в которых тесно переплетены многие сущности. И ведь именно для таких областей наши информационные системы могут оказаться особенно полезны - если мы хоть немного помогли справиться со сложностью, то мы герои. И вот для таких сложных случаев и нужны, скажем, паттерны из "синей книги" - там ведь не только про то, что надо разделять и властвовать, но и про связи между компонентами - как добавлять эти связи так, чтобы не получилось "монструозного кубера". На ютубе есть выступление Эванса как раз про микросервисы и DDD кстати.
Дело в том, что я не искал метафору в статье, а описал выводы, которые сделал из собственной практики, когда на себе попробовал микросервисы со многими сущностями и сравнил их с микросервисом из одного агрегата. Как говориться, tremendous difference. Думаю, что все возражения к статье сводятся к тому, что большинство людей воспринимает DDD как отстраненную теорию, хотя она, на самом деле, самая что ни на есть практическая инструкция к действию. Но пока не попробуешь на себе - не узнаешь, работает ли предложенный в статье подход или нет.
В статье написаны только положительные моменты. А как же минусы микросервисов(распределенные транзакции, отладка и т.д.) они не усугубляются?
Усугубляются, конечно. CAP-теорему никто не отменял. Но выгоды, с моей точки зрения, перетягивают
Отдельно стоит сказать про отладку - как раз она становится в разы более легкой.
А всё остальное довольно хорошо решается документированием , которое для простых микросервисов выглядит гораздо проще для понимания. В сочетании с луковой архитектурой изучить документацию становится легко
Статья хорошая. Самое главное в ней, это то что главное при проектировании это разметка предметногл поля. И как пример - микросервисы. Это авторское видение. Автор имеет право.
Т.е. это обозначает, что бизнес и разработка всегда будут «говорить» про одно и то же. Если бизнес говорит «Заказ», то разработка понимает, что речь идёт о микросервисе «Заказ». Если бизнес говорит «Корзина», то разработка понимает, что речь идёт о микросервисе «Корзина». Если бизнес говорит «Поставка», то речь о микросервисе «Поставка».
Крайне рекомендую автору статьи и всем заинтересовавшимся посмотреть выступление https://www.youtube.com/watch?v=hev65ozmYPI ("All your aggregates are wrong") .
В докладе рассматривается буквально такой же подбор компонентов как в упомянутой цитате, с разбором почему такое структурирование может вылиться в проблемы с работой и поддержкой системы.
"Микросервис = Сущность предметной области, и не более."
"Относительно небольшое число микросервисов даже в больших корпорациях"
Только я тут вижу прямое противоречие?
В больших системах сущностей может быть сотни. Если же их немного, то в нормальном модульном монолите тоже не запутаешься
И... Микросервисы - просто? Когда одни сервисы стучатся в другие, когда получаются распределенные транзакции и начинаются новые модные штуки типа двухфазных фиксаций, саг и т.п. что конечно же "упрощает" архитектуру и "способствует ее более простому восприятию". Также соблюдение контрактов при общении между сервисами, выкатка изменений, когда у тебя меняется сразу несколько сервисов в одной фиче. Про время взаимодействия между сервисами уже промолчу. Про документацию на каждый сервис тоже отдельный момент - не встречал ещё разработчиков, кто любит писать доки)
Если есть микросервисы и на каждый отдельная команда - это удобно(конечно же с оговорками). Но если у тебя 20 микросервисов на одну команду и это можно было бы реализовать монолитом, на мой взгляд проще и писать такое, и быстрее в него вникнешь. Конечно же, это не отменяет разбиение на модули/контексты.
Системы маленькие по размеру - в них легко разобраться и дорабатывать
Вместо того чтобы разбираться в одной непонятной системе, давайте будем разбираться в 400 понятных системах
DDD – это микросервисная архитектура на базе сущностей предметной области.
Где вы нашли такое определение DDD?
В Wiki ничего про микросервисы не сказано:
https://ru.wikipedia.org/wiki/Предметно-ориентированное_проектирование
Вы нарушаете главный смысл микросервисов. Они должны быть разные и подстроиться под свои конкретные задачи. Также DDD это бред, мы не моделируем предметную область, мы создаём процессы и их автоматизируем.
Если делать завод по DDD вы сделаете антропоморфных роботов которые собирают машины руками и пьют чаи на пересменке, потому что так работает домен. Нет никаких доменов, нет никаких агрегатов, есть процессы которые нуждаются в автоматизации, не в переносе процесса и его сущностей в программу.
DDD простыми словами