В документациях по микросервисной архитектуре для сложных сущностей рекомендуют делать микросервисы-витрины, которые агрегируют данные из микросервисов-сущностей и предоставляют их потребителям.
Кажется, что решить эту проблему можно, если сделать над сервисами-сущностями отдельный “слой” сервис, которые инкапсулируют в себя всю логику. Но обычно это тоже плохо заканчивается. Потому что тогда сервисы-сущности становятся сервисами-хранилищами, т.е. вся бизнес-логика из них вымывается, кроме хранения.
Этот отдельный слой называется хореограф или оркестратор, паттерн типа Саги и т.д. Все верно, его задача — реализовывать бизнес-логику и манипулировать данными из микросервисов-хранилищ (забирая из через API). Что в этом автор увидел плохого, непонятно.
Пример. Для менеджера, который работает с наполнением товарной номенклатуры, главными фичами будут возможность удобно добавлять товар, удалять, менять и просматривать. Нагрузки немного, если разделить в отдельные сервисы чтение и изменение, мы от такого разделения ничего не получим, кроме проблем, когда придется делать в сервисах согласованные изменения.
А зачем в данном примере что-то разделять? CQRS надо использовать только там, где это необходимо.
Все это здорово и правильно, поддерживаю двумя руками.
Но необходимо учитывать, что часть вакансий (возможно, даже, бОльшая) создана для того, чтобы решить какие-то конкретные проблемы организации «здесь и сейчас», а не через 1-2-5 лет. Соответственно, и специалист им необходим для этого с конкретными знаниями конкретных технологий «здесь и сейчас».
В плане перехода программистов в менеджеры меня всегда интересовал один момент. В подавляющем большинстве случаев (статистики, правда, нет, это субъективное мнение) программисты являются интровертами, которым проще играть умом и решать задачи, нежели общаться с человечеством. С другой стороны, чтобы выполнять компетенции менеджера, необходимо обладать экстравертными способностями: с удовольствием общаться с людьми, не бояться стрессовых разговоров, находиться в состоянии неопределенности (результаты не зависят от тебя, а зависят от команды), играть эмоциями, и т.д. Выработать абсолютно противоположные черты своего характера невозможно, можно только пытаться соответствовать образу и каждый день играть непривычную тебе роль. Что делает человека чуточку менее счастливым.
Возможно, оставаться профессионалом в той области, к которой есть предрасположенность, не так уж и плохо.
Вспомнился фильм «Явление» 2008 года, где растениям надоели люди и они начали выпускать в воздух токсин, заставляющий совершать самоубийство. Прочитал статью, и фильм уже не кажется полным бредом. Люди, берегите природу!
В документациях по микросервисной архитектуре для сложных сущностей рекомендуют делать микросервисы-витрины, которые агрегируют данные из микросервисов-сущностей и предоставляют их потребителям.
Этот отдельный слой называется хореограф или оркестратор, паттерн типа Саги и т.д. Все верно, его задача — реализовывать бизнес-логику и манипулировать данными из микросервисов-хранилищ (забирая из через API). Что в этом автор увидел плохого, непонятно.
А зачем в данном примере что-то разделять? CQRS надо использовать только там, где это необходимо.
Но необходимо учитывать, что часть вакансий (возможно, даже, бОльшая) создана для того, чтобы решить какие-то конкретные проблемы организации «здесь и сейчас», а не через 1-2-5 лет. Соответственно, и специалист им необходим для этого с конкретными знаниями конкретных технологий «здесь и сейчас».
Возможно, оставаться профессионалом в той области, к которой есть предрасположенность, не так уж и плохо.