Это только разрабы

Ну и тестров может 20 на вскидку

И мне кажется, что чем больше проект, тем более преимуществ от древовидной компонетизации. У компонентов есть ответственные люди и они за ними следят. Т.к. всё отвязано, то проще поддерживать.

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

Ну, замечательно, что у вас всё так хорошо. У нас нет таких ресурсов, чтобы плодить кучу экранных ивентов и маппить их на ивенты фичи, а потом отлавливать неконстистентности состояний в разных местах. А они наверняка будут (у нас были, лол), потому что пропадает профит от SSoT

Объективно, для нас мастер-фича это лучшее решение, есть только сомнения в том, как генерализовать процесс "сливания" фич

Согласен, всё зависит от ресурсов и размера команды. При большой команде появляется необходимость одновременно пилить фичи без конфликтов и от вечать за свою часть проекта. В этом случае декомпозиция на маленькие компоненты, каждый со своим SSoT, даёт преимущество. У нас некоторые компоненты по 5 раз или даже больше переиспользуются. И могут одновременно присутствовать в нескольких экземплярах. Можно их даже в RecyclerView в ставлять, вроде.

Скажем можно сделать компонент РекламныйБанер, и вставлять его куда надо и он сам работает.

А, вот ещё, по тому какие у меня мысли были: изолированная связка фича-компонент это хорошо, но что, если бы флоу

event ---- component
  |         ^
  v         |
feature -- state

Можно было прерывать на диагонали event и state? Тогда компонент на самом деле был бы "розеткой" с оутпутом типа Event и инпутом типа State, в который можно было бы вставлять любую подходящую фичу
Хотя я вот хз, возможно у вас это так и работает и я тут не открыл Америку

Да, мы тоже так делаем.

event ---- component
  |         ^
  v         |
feature -- state

Я не очень понимаю, как это фича общается с компонентом. Что такое фича?

аналогично фиче из MVICore

Аа, тогда у нас фича не общается с компонентом. Она в нём лежит и не видна из вне.

Состояния фичи идут во вью, события вью в фичу. Ну и другие источники/потребители могут быть

Например аналитика

А у компонента нет публичного состояния. Его состояние это состояние фичи, либо набор состояний, если фичей несколько.

Ну вот, об этом я и говорю. Функция компонента, которая делает рендер состояния эффективно чистая (нет других сайд-эффектов, кроме как привести UI к нужной форме). Аналогично, ивенты достаточно детерминированы, чтобы некая внешняя сущность, которая их поглощает, могла надеяться, что ей не врут.
Тогда компонент экспозит свою фичу, а сущность повыше, которая конструирует компонент, при желании может "выдернуть" флоу, перетащить ивенты в какое-то другое место и из этого же другого места доставлять стейты для рендера

Зачем это делать? Опять же, например, для мастер фичи

Очевидно, что нет смысла выдергивать ивент-стейт флоу из какого-нибудь рекламного баннера, но на экранах, где есть несколько логически пересекающихся компонентов я считаю это гораздо удобнее, чем экранные ивенты вкостыливать

event ---- component
  |         ^
  v         |
feature -- state

Это называется BLoC pattern