Как стать автором
Обновить

Рациональный подход к декомпозиции систем на модули или микросервисы

Уровень сложности Сложный
Время на прочтение 13 мин
Количество просмотров 6.2K
Всего голосов 13: ↑13 и ↓0 +13
Комментарии 7

Комментарии 7

подмножество Event Storming

Это не совсем так.

Основное отличие в том, что ДДД и ЭШ требует вовлеченности и "образованности" большого количества людей, а это не всегда возможно. Для этих случаев я и разработал декомпозицию на базе эффектов, которую может выполнить один человек и которая даёт достаточно хорошие результаты.

упрощенная до трехзвенной модель.

Это совсем не так:)

Способ реализации не зашит ни в концептуальную модель, ни в подход к декомпозиции и спроектированная таким образом система может быть реализована как угодно - я предпочитаю функциональную архитектуру, но не вижу никаких препятствий к тому, чтобы реализовать её хоть в виде гексагональной, хоть cqrs/вертикальной, хоть той же трёхзвенной модели. Надеюсь вы имели ввиду трёхуровневую архитектуру (более привычнй мне термин), а не трёхзвенную уголовную модель в казахстане 🤣

Что увидел в нотации по сравнению со Стормингом. События — События, Ресурсы — Агрегаты, Эффекты — Команды, Операции — Группы команд. Отказываемся от пользователя, экспертов домена, их глоссария. Скорее всего, теряем часть их NFRов и событий. Тогда свернутый в микросервисы граф будет иметь неверные границы. По заветам аджайл, пытаемся рефакторить после релиза по мере поступления уточнений от пользователей. Рефакторинг границ в МСА это очень дорого. Поэтому с каждой итерацией связываем постепенно всех со всеми.

Мотив проектировать в одиночку понятен, не от хорошей жизни, но проваливается на сколько нибудь крупных системах, которые не помещаются в одну голову. На ArchDays называли анти-паттерном.

Слово микросервисы в названии - ради кликбейта, у меня МСы имеют штраф в 100 у.е. и я начинаю бить систему на разные процессы только когда по другому никак:)

Что увидел в нотации по сравнению со Стормингом. События — События,
Ресурсы — Агрегаты, Эффекты — Команды, Операции — Группы команд

Сходство и правда есть, но не полное.
Ресурсы - включают агрегаты, но не только.
Эффекты - это отдельные операции по чтению и модификации состояния
Операции - вот это аналог команд.

Отказываемся от пользователя, экспертов домена, их глоссария.

Именно отказаться цели нет - по возможности их по максимуму надо задействовать, опрашивать и учитывать. Но когда их добыть не получается - да, опираемся на своё понимание.

теряем часть их NFRов

Если есть возможность их намайнить - не теряем. В декомпозиции учитываем принимая экспертные решения в сложных случаях и агрегации ресурсов, либо вообще отходя от алгоритма. И перепроверяем на этапе оптимизации

но проваливается на сколько нибудь крупных системах, которые не помещаются в одну голову.

К текущему моменту этот подход я апробировал на 6 коммерческих проектах 1-12 человеко-месяцев. И я не думаю, что я буду когда-то "up front" проектировать систему на 10 человеко-лет. А если система не помещается в одну голову - это уже 101 балл в пользу разбиения системы на несколько.

Спасибо за подробности. Согласен, проекты на пару месяцев на троих, где все шарят в предметной области часто лучше заказчика (энтерпрайз смотрит на нас снисходительно), в Сторминге не нуждаются.

Хорошая информация, остановился на ссылке - про декомпозицию https://azhidkov.pro/posts/22/08/ergonomic-decomposition, к статье еще вернусь.
По блогу рекомендация - добавить возможность обсуждений (например Disqus) или просто возможность тыкнуть плюс. Прикрутить RSS тоже было бы здорово =)

Спасибо:)

Обсуждать и тыкать плюсы (и минусы) можно (и нужно) телеграмме:)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий