Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.
Бывает, что компании решают использовать микросервисный подход, но в результате получают таких же монолитных монстров, но только работающих в Кубере.
Симптомы:
Между командами происходит борьба на чьей стороне должен быть разработан новый функционал
Каждая команда считает, что на её стороне, либо же наоборот, хочет сбросить с себя новый функционал и перекинуть его на другую команду
Происходит это чаще всего из-за того, что границы систем размыты и нет чёткого понимания, что должно входить в систему, а что нет.
Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы.
По сути, речь идёт о том, что системы становится слишком большими и для их доработки требуется длительный процесс погружения.
Можно ли исправить ситуацию коренным образом?
Простое решение для сложной проблемы
Для начала вспомним проблемы:
Системы большие по размеру - они жрут много ресурсов и сложны в сопровождении
Системы сложные и в них трудно разобраться, поэтому существуют специализированные команды по разработке конкретных систем
Нет четких границ систем, поэтому между командами возникают битвы за функционал
Теперь давайте представим обратную ситуацию:
Системы маленькие по размеру - в них легко разобраться и дорабатывать
Системы очень простые и разобраться в них элементарно - специализированные команды становятся не нужны
Есть кристально чёткие границы систем - битвы между командами за функционал уходят в историю
Возможно ли такое вообще?
Большинство скажет, что нет, невозможно. Но некоторые все же ответят: да, возможно, и будут правы.
Если освободиться от устаревших установок и неработающих политик, то становится очевидно, что сделать систему, состоящую из простых и несложных компонент все же можно.
Есть такой подход – DDD (Domain Driven Design), который как раз и предлагает способ построение больших систем на основе супер-простых элементарных компонент.
DDD – это микросервисная архитектура на базе сущностей предметной области.
Атомами системы выступают малюсенькие микросервисы, соответствующие элементарным понятиям бизнесовой предметной области.
Специально для этих целей вводится понятие «Единого языка» (Ubiquitous language).
Единый язык в этом контексте обозначает, что Микросервис = Сущность предметной области, и не более.
Т.е. это обозначает, что бизнес и разработка всегда будут «говорить» про одно и то же. Если бизнес говорит «Заказ», то разработка понимает, что речь идёт о микросервисе «Заказ». Если бизнес говорит «Корзина», то разработка понимает, что речь идёт о микросервисе «Корзина». Если бизнес говорит «Поставка», то речь о микросервисе «Поставка».
Фактически говорится, что микросервисы создаются четко под бизнес-сущности, а не каким-то другим специфическим образом.
Понятие «Система» в корпоративном понимании монструозного приложения уходит в прошлое, а на её место приходят десятки мелких бизнес-ориентированных равнозначных одноуровневых микросервисов.
Понятные чёткие границы
С чего начинается любая разработка? С того, что бизнес пытается объяснить разработчикам чего он хочет.
Например, приходит бизнес и говорит: я хочу сократить время вывода новых продуктов на рынок.
Конечно, Вы сразу же просите пояснить, что он под этим имеет ввиду?
Бизнес начинает описывать процесс: «Хочу, чтобы поставщик самостоятельно заводил описание новой товарной номенклатуры, а затем загружал её к нам. После проверки и полной загрузки номенклатура должна одномоментно появится во всех каналах продаж (офисы продаж, интернет-магазин, мобильное приложение)»
В самой формулировке бизнеса содержится ответ на вопрос о границах.
В бизнес-описании фигурируют следующие сущности предметной области:
Товарная номенклатура
Канал продаж
Т.к. сущности предметной области являются микросервисами, то сразу же очевидно какие микросервисы будут меняться - "Товарная номенклатура" и "Канал продаж".
Также сразу можно выделить и операции с этими микросервисами, которые необходимо реализовать в рамках доработки.
Операции с товарной номенклатурой (взятые из бизнес-описания) могут быть, например, такими (выделены жирным шрифтом в бизнес-описании):
Создать
Загрузить
Проверить
Показать
Свойства номенклатуры:
Описание
Статус показа номенклатуры в каналах продаж (показывается/не показывается)
Статус полноты загрузки (полностью/не полностью)
Бизнес-правила:
Номенклатура может быть показана только при её полной загрузке и проверке
Номенклатура может быть загружена только пакетом
Как-то так.
Мелкие микросервисы
Действительно ли в результате получаются мелкие микросервисы? Чтобы это понять, давайте взглянем для начала на микросервис «Канал продаж».
Какие свойства канала продаж Вам приходят в голову исходя из бизнес-описания?
Да кроме названия канала там больше ничего и нет. Т.е. весь микросервис будет состоять из одной таблицы с двумя полями - первичным ключом и названием.
Теперь посмотрим на вариант посложнее: что будет представлять из себя микросервис «Номенклатура»?
Очевидно, что там будет таблица с номенклатурными позициями, а также таблица с загруженными пакетами и результатами их проверки. Т.е. порядка 3-5 таблиц.
Легко разобраться и понять
Небольшой размер микросервисов в сочетании с простой внутренней архитектурой (например, «луковой») даёт феноменальный результат, когда сделать правки в микросервис может, в буквальном смысле, даже неподготовленный разработчик.
«Луковая» архитектура, когда применяется одинаково ко всем микросервисам сразу, позволяет сходу понять куда именно в микросервисе встроится, чтобы корректно сделать правки.
Суть архитектуры в том, что в ней выделяются чёткие слои: входные и выходные адаптеры, уровень сервисов приложения, уровни доменной модели и инфраструктуры.
Любой разработчик, если понимает суть луковой архитектуры, быстро найдет где именно и что ему надо встроить.
Результат – децентрализация команд, возможность подключения команд к разработке любого микросервиса в компании, ненужность специализации на одной системе.
Выводы
Если отбросить шелуху и красивые иностранные слова наподобие «Bounded context», «Event storming» и проч., которые только путают, то в остатке остается весьма красивая, простая и доступная для понимания концепция корпоративной микросервисной архитектуры.
Основные преимущества концепции DDD:
Единый язык с бизнесом
Кристально чёткие границы микросервисов
Простая внутренняя структура
Легкость понимания неподготовленным разработчиком
Относительно небольшое число микросервисов даже в больших корпорациях
Конечно, как и любой другой архитектурный подход, она требует понимания и анализа применимости в каждой конкретной ситуации.
Пользуйтесь, получайте выгоду и упрощайте себе жизнь.
Оставьте свой комментарий – выскажите своё мнение о концепции и о статье.
Комментарии (37)
andToxa
23.04.2024 14:14+6Единый язык в этом контексте обозначает, что Микросервис = Сущность предметной области, и не более.
может быть все-таки не сущность, а ограниченный контекст?
varenich Автор
23.04.2024 14:14А есть разница?
andToxa
23.04.2024 14:14+1в одном ограниченном контексте может быть много сущностей
varenich Автор
23.04.2024 14:14и какой отсюда вывод? Что такое, на Ваш взгляд, ограниченный контекст?
DenSigma
23.04.2024 14:14+2Ну как я понимаю, Счет и Начисления счета - это грубо говоря, ограниченный контекст, а сущности - Счет и Начисление.
Вы предлагаете уж совсем мелкое деление. Счет - в отдельном МС, Начисление - в отдельном МС. А они не существуют и не могут существовать друг без друга, и обработка их должна вестись в одной функции.
varenich Автор
23.04.2024 14:14Каких именно сущностей и почему много? В этом весь вопрос. И не превратится ли это "много" в очередную монструозную систему на базе кубера, как это, в основном, и происходит?
Alpensin
23.04.2024 14:14+2Сущность это конкретный термин в DDD. Он же Entity. Их может быть несколько в контексте.
YegorP
23.04.2024 14:14+10DDD – это микросервисная архитектура на базе сущностей предметной области.
Горшочек, не вари. Хватит уже микросервисов. Уже и к DDD их приплели.
DDD без микросервисов - возможны. Микросервисы без DDD - тоже. Ортогональные подходы абсолютно.
varenich Автор
23.04.2024 14:14У Вас отрицательный опыт работы с микросервисами? Что с ними не так и почему DDD не надо лепить к микросервисам?
YegorP
23.04.2024 14:14+2Да потому что DDD можно применять там, где в итоге невозможны микросервисы, что ставит под вопрос их безоговорочную привязку. Ещё потому что DDD это про очерчивание сущностей по бизнес-требованиям, и есть разные подходы к этому даже в general-purpose языках. Способ взаимодействия модулей (монолит/микро/макро/хоть что) тут вообще ни при чём. Эти подходы можно успешно объединить, да, но нельзя сказать, что они по умолчанию связаны.
varenich Автор
23.04.2024 14:14Но это как-то не отвечает на Ваше же собственный комментарий, что нельзя совмещать DDD и микросервисы. Пока что Ваши доводы говорят как раз об обратном - что можно это делать. Как так?
bloomdido
23.04.2024 14:14+1Если это воспринимать как метафору, т.е. "DDD - это как микросервисная архитектура, но для наших ментальных моделей, отражаемых в коде, а не для самого кода и его технологической обвязки", то это довольно удачная метафора, не описывает все DDD, но указывает на ключевые вещи. Но у вас в статье получилось слишком буквальное сравнение, что понятно - вы старались донести действительно удачную метафору. Все возражения как мне кажется по поводу этой буквальности. Но для начала обсуждения неплохо. Скажем вы пишете в ответе на другой коммент: "И не превратится ли это "много" в очередную монструозную систему на базе кубера?" - хороший вопрос! Но бывают действительно сложные предметные области, в которых тесно переплетены многие сущности. И ведь именно для таких областей наши информационные системы могут оказаться особенно полезны - если мы хоть немного помогли справиться со сложностью, то мы герои. И вот для таких сложных случаев и нужны, скажем, паттерны из "синей книги" - там ведь не только про то, что надо разделять и властвовать, но и про связи между компонентами - как добавлять эти связи так, чтобы не получилось "монструозного кубера". На ютубе есть выступление Эванса как раз про микросервисы и DDD кстати.
varenich Автор
23.04.2024 14:14+1Дело в том, что я не искал метафору в статье, а описал выводы, которые сделал из собственной практики, когда на себе попробовал микросервисы со многими сущностями и сравнил их с микросервисом из одного агрегата. Как говориться, tremendous difference. Думаю, что все возражения к статье сводятся к тому, что большинство людей воспринимает DDD как отстраненную теорию, хотя она, на самом деле, самая что ни на есть практическая инструкция к действию. Но пока не попробуешь на себе - не узнаешь, работает ли предложенный в статье подход или нет.
ddd06
23.04.2024 14:14+1В статье написаны только положительные моменты. А как же минусы микросервисов(распределенные транзакции, отладка и т.д.) они не усугубляются?
varenich Автор
23.04.2024 14:14Усугубляются, конечно. CAP-теорему никто не отменял. Но выгоды, с моей точки зрения, перетягивают
varenich Автор
23.04.2024 14:14Отдельно стоит сказать про отладку - как раз она становится в разы более легкой.
А всё остальное довольно хорошо решается документированием , которое для простых микросервисов выглядит гораздо проще для понимания. В сочетании с луковой архитектурой изучить документацию становится легко
DrRaznomazov
23.04.2024 14:14Статья хорошая. Самое главное в ней, это то что главное при проектировании это разметка предметногл поля. И как пример - микросервисы. Это авторское видение. Автор имеет право.
Haze27
"DDD – это микросервисная архитектура на базе сущностей предметной области. "
Разве DDD относится только к микросервисам?) вроде как смысл в логическом разделении данных
varenich Автор
Вероятно, каждый понимает её по своему, но если почитать синюю и красную книги, то там речь идет именно о системах/микросервисах, скрывающихся под ограниченными контекстами. Более того, в книгах огромные разделы посвящены именно построению микросервисов на основе DDD
Haze27
Увы нет на руках этих книг, но даже нас в университете учили, что 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", то есть соответствует, а не является
varenich Автор
Если попробовать применить DDD на практике, то становится понятным, что само понятие домена - чисто информационная вещь, которую особо никак не используешь. В реальности очень многие сущности предметной области (ограниченные контексты) могут входить (и входят) сразу в несколько доменов. А если сделать следующий шаг и подумать над ПРАКТИЧЕСКОЙ целью DDD, то становится очевидным, что концепция создавалась в первую очередь для упрощения микросервисной архитектуры
funca
Есть хороший разбор книг Эванса и Вернона в трёх частях 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, базами данных и т.п.
Микросервисы это просто один из паттернов реализации приложения, построенный на идеях компонентной архитектуры. Есть и другие. Например вы можете завернуть их в приложение для десктопа или телефона, сделав ближе к пользователю. Или монолита - упростив развертывание. Или ... Все будет зависеть от остальных требований.
soul-catcher
А что у вас за университет был? В моём такого не было, а хотелось бы.
Haze27
РТУ МИРЭА, прикладная информатика
dyadyaSerezha
Вот именно что на основе. DDD сам по себе совершенно не связан с микросервисами.
Далее, разбиение проектируемой системы на всё более мелкие и простые части - основа вообще любого метода проектирования, и DDD или микросервисы тут вообще не могут претендовать на уникальность.
Далее, многое в DDD является просто стандартом де факто в любом объектно-ориентированном подходе, где классы соответствуют сущностям домена, а их методы - действиям над сущностями. Это стандарт с начала 90-х, так что ничего нового.
Далее, если заменить слово "микросервис" (точнее, "ограниченный контекст") на "модуль" или "подсистема", то все преимущества будут те же для любого монолита. Более того, монолиты требуют меньше ресурсов, так как избегают дуплицирования многих нижних уровней.
Итого - все описанные в статье принципы и плюсы полностью применимы к монолитам и любым другим вариантам системы/продукта.
Кстати, слово "система" никуда не девается в варианте микросервисов.
varenich Автор
Главное, чтобы это не было т.н. "ложным убеждением". На основании чего Вы это утверждаете?
Просто попробуйте представить, что ситуация может быть как раз обратной.
Все остальные доводы в ответе следуют из первого утверждения, как я понимаю.