Комментарии 7
Похоже на подмножество Event Storming, упрощенная до трехзвенной модель.
подмножество Event Storming
Это не совсем так.
Основное отличие в том, что ДДД и ЭШ требует вовлеченности и "образованности" большого количества людей, а это не всегда возможно. Для этих случаев я и разработал декомпозицию на базе эффектов, которую может выполнить один человек и которая даёт достаточно хорошие результаты.
упрощенная до трехзвенной модель.
Это совсем не так:)
Способ реализации не зашит ни в концептуальную модель, ни в подход к декомпозиции и спроектированная таким образом система может быть реализована как угодно - я предпочитаю функциональную архитектуру, но не вижу никаких препятствий к тому, чтобы реализовать её хоть в виде гексагональной, хоть cqrs/вертикальной, хоть той же трёхзвенной модели. Надеюсь вы имели ввиду трёхуровневую архитектуру (более привычнй мне термин), а не трёхзвенную уголовную модель в казахстане 🤣
Что увидел в нотации по сравнению со Стормингом. События — События, Ресурсы — Агрегаты, Эффекты — Команды, Операции — Группы команд. Отказываемся от пользователя, экспертов домена, их глоссария. Скорее всего, теряем часть их NFRов и событий. Тогда свернутый в микросервисы граф будет иметь неверные границы. По заветам аджайл, пытаемся рефакторить после релиза по мере поступления уточнений от пользователей. Рефакторинг границ в МСА это очень дорого. Поэтому с каждой итерацией связываем постепенно всех со всеми.
Мотив проектировать в одиночку понятен, не от хорошей жизни, но проваливается на сколько нибудь крупных системах, которые не помещаются в одну голову. На ArchDays называли анти-паттерном.
Слово микросервисы в названии - ради кликбейта, у меня МСы имеют штраф в 100 у.е. и я начинаю бить систему на разные процессы только когда по другому никак:)
Что увидел в нотации по сравнению со Стормингом. События — События,
Ресурсы — Агрегаты, Эффекты — Команды, Операции — Группы команд
Сходство и правда есть, но не полное.
Ресурсы - включают агрегаты, но не только.
Эффекты - это отдельные операции по чтению и модификации состояния
Операции - вот это аналог команд.
Отказываемся от пользователя, экспертов домена, их глоссария.
Именно отказаться цели нет - по возможности их по максимуму надо задействовать, опрашивать и учитывать. Но когда их добыть не получается - да, опираемся на своё понимание.
теряем часть их NFRов
Если есть возможность их намайнить - не теряем. В декомпозиции учитываем принимая экспертные решения в сложных случаях и агрегации ресурсов, либо вообще отходя от алгоритма. И перепроверяем на этапе оптимизации
но проваливается на сколько нибудь крупных системах, которые не помещаются в одну голову.
К текущему моменту этот подход я апробировал на 6 коммерческих проектах 1-12 человеко-месяцев. И я не думаю, что я буду когда-то "up front" проектировать систему на 10 человеко-лет. А если система не помещается в одну голову - это уже 101 балл в пользу разбиения системы на несколько.
Хорошая информация, остановился на ссылке - про декомпозицию https://azhidkov.pro/posts/22/08/ergonomic-decomposition, к статье еще вернусь.
По блогу рекомендация - добавить возможность обсуждений (например Disqus) или просто возможность тыкнуть плюс. Прикрутить RSS тоже было бы здорово =)
Спасибо:)
Обсуждать и тыкать плюсы (и минусы) можно (и нужно) телеграмме:)
Рациональный подход к декомпозиции систем на модули или микросервисы