Что лучше разделять между backend, web и mobile: бизнес-правила, готовые модули или только контракты? Ошибка здесь часто выглядит как экономия, а заканчивается связанным релизом трех продуктов.

Идея "давайте вынесем общую бизнес-логику в одно место" звучит разумно. Меньше дублирования, единое поведение, проще исправлять ошибки. Но у этой идеи есть опасное продолжение: начать считать одинаковым все, что связано с одним доменом.

У разных поверхностей разные ограничения. Web может менять интерфейс каждую неделю. Mobile живет в мире версий приложения и не мгновенных обновлений. Backend отвечает за данные, безопасность, транзакции и совместимость.

Если заставить их использовать один и тот же слой без четкой границы, общая логика быстро превращается в общий узел связанности.

Я бы разделял систему на три уровня.

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

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

— Адаптеры и представление. Здесь платформы могут быть разными. Web, mobile и внутренний инструмент не обязаны повторять друг друга, если они соблюдают правила и контракт.

Практический тест простой: если изменение интерфейса требует синхронного релиза backend и мобильного приложения, граница, вероятно, проведена слишком глубоко.

Если изменение правила приходится вручную повторять в трех кодовых базах, граница, наоборот, слишком слабая.

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

Это четыре разных решения с разной ценой.

Хорошая архитектура не заставляет все части системы быть одинаковыми. Она делает различия управляемыми, а общие правила — проверяемыми.

А где у вас проходит граница между повторным использованием и опасной связанностью?

#backend #architecture #platformengineering #engineering #teamlead #izagprog