В приложении есть проекты. Их участники создают задачи и публикуют отчёты. За участников, задачи и отчёты отвечают разные модули. Внутри каждого — аккуратные слои, тесты проходят, зависимости направлены правильно.

Однажды появляется временная блокировка. Участник остаётся в проекте, но работать больше не должен. Создание задачи уже запрещено. А вот отчёт всё ещё можно отправить.

В одном модуле правило звучало как «разрешить только активному». В другом — «запретить отозванному». Пока состояний было два, результаты совпадали. С появлением третьего правила разошлись. При этом внутри каждого модуля архитектура могла остаться вполне чистой.

Первое решение, которое приходит в голову, — вынести участника в `shared`. Второе — держать собственную модель в каждом модуле и не связывать их импортами. Однако вопрос шире размещения класса: кто отвечает за состояние членства, кто принимает решение о доступе и как остальные узнают об изменении? Общая модель позволяет держать правило в одном месте. Но её версия должна дойти до каждого потребителя, а старое приложение на телефоне само по себе не обновится. Если в общий пакет попадут детали отчётов и хранения, задачи тоже начнут от них зависеть.

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

Есть и другой путь: оставить полную модель у модуля участников, а соседям предоставить узкий ответ — действие разрешено, запрещено или сведения сейчас недоступны. Последнее состояние важно: сбой связи не означает, что пользователя заблокировали.

События помогут сообщать соседним модулям об изменении, но не гарантируют мгновенного обновления. Пока событие обрабатывается, экран может показывать прежний статус. А сервер при записи должен учитывать и более тонкую ситуацию: блокировка могла произойти уже после проверки доступа.

Все эти варианты можно сочетать. Важно понимать цену каждого и проверять не только отдельные модули, но и одно поведение на их границах. Для пользователя задачи и отчёты остаются частью одного проекта.

В полной статье ArkTelos Lab — примеры на Dart, сравнение решений и вопросы, которые помогают выбрать границу для своего проекта: читать статью. ArkTelos: сайт: https://arktelos.dev/ru ArkTelos Lab: https://labs.arktelos.dev/ru English article: https://labs.arktelos.dev/en/articles/cross-module-domain-entity/ Telegram: Lab RU: https://t.me/arktelos_lab_ru Lab EN: https://t.me/arktelos_lab ArkTelos RU: https://t.me/arktelos_ru ArkTelos EN: https://t.me/arktelos