Был у меня момент, многомодульный Maven-based проект на 30+ модулей с 3М+ LOC, IDEA решила задуматься с индексированием на пару-тройку часов

Так что отвечая тебе на вопрос - я профит от многомодульности вижу тольео в стандартизации зависимостей по большому счёту, а для этого хватит и parent POM, например

Я больше о ситуации когда "на выходе имеем много маленьких PRов вместо одного большого". По моему это - еще больший геморрой чем один большой PR: этот хотя бы атомарен.

Профит от многомодульности везде один, как бы на модули не разбивали. Reuse и Release. Просто коряво разбитое на мавен модули приложение хоть и ведет к большим PRам, но хотя бы по одному на фичу. В отличие от коряво разбитого на модули приложения где модули разнесены по репам.

Ну, атомарен или нет - дело другое. VCS тебе вполне позволит проверить эффективность, например, одного из серии однотипных мелких PR и принять решение нужен он тебе в итоге или нет, а не ломить все сразу везде.

Нафиг мне этим заниматься? Вопрос стоит - нужна фича в апстриме или нет, почему меня должны интересовать ее куски?

Или я мысль не понял

Минимизация человеческой ошибки? Скажем, абстрактный такой кейс - пришёл новый архитектор в контору и сказал что CQRS - это мега охуенно и нужно запилить везде. Где-то оно может и приживётся, а где-то оно бестолково

Ты ж не будешь скопом весь такой PR мёржить и потом разгребать что где получилось

А. Такого рода фичи? Я больше имел ввиду имплементацию каких нить бизнес-сценариев

Чем тебе CQRS не реализация бизнес-сценария, скажем, грамотного поведения пользовательской корзины с покупками?

Кроме того хотелку архи "CQRS это круто" по логике неплохо бы свести к подхотелкам "заиметь CQRS в сервисе N" и трекать их отдельными тасками

Согласен, но внутри одного эпика / стори / кто как привык

Епик не существенен - атомарность будет на уровне таски

P.S. А где пункт б? :)

Нет пункта б. В комменте "а" это просто восклицание.

Бизнес не ругается словами вроде CQRS, поэтому я не считаю фичу такого рода бизнес-фичей. CQRS это, как максимум, одна из возможных реализаций гипотетической бизнес фичи.

Хм, речь о таком архитекторе. У нас тогда похожая система походу. Т.е. отдельного "умника" который всех учит как правильно жить, но сам нихера не делает нет. Вопросы по стеку или глобальные технические вопросы часто решаются коллегиально. Ещё чаще - экспериментально. Человек который у нас называется архитектором вообще в основном отвечает за правильную постановку бизнес-требований оверолл по всем компонентам системы, коммуникацию их с заказчиком/закзачиками и прочие глобальные вопросы.  
Стек: Джава.
Уровень в команде: различный.
Ну т.е. как и писалось выше - истории по разному складываются.

> "умника" который всех учит как правильно жить, но сам нихера не делает нет

Такой умник - это чувак с полномочиями но без ответственности. Я не за него ратовал.

👍