Scs
Self-Contained Systems (SCS)¶
Self-Contained System — это автономная веб-система-вертикаль, которая включает свой UI, бизнес-логику и данные и владеет своим куском функциональности end-to-end.
- придумали в INNOQ, публично оформили на scs-architecture.org примерно в 2015, главный рупор — Stefan Tilkov.
- ключевое слово — вертикаль. Не слой, не сервис под чужим фронтом. Целый кусок продукта от пикселя в браузере до строки в своей БД.
- SCS почти не вызывает чужую логику синхронно в рантайме. Если интеграция и есть — то через ссылки, UI-композицию или async. Это главное, что отличает SCS от привычного service mesh.
Грубо говоря: берёшь большой портал, режешь его не на технические слои, а на самостоятельные веб-приложения по бизнес-областям. Каждое можно выкатить, уронить и переписать отдельно.
Принципы
Канонический список с scs-architecture.org, без воды:
- автономия — каждый SCS отдельное веб-приложение, деплоится независимо, своя кодовая база.
- своя БД — никакого shared database между SCS. Данные дублируются, а не шарятся.
- своя логика и свой UI — UI не отдельный фронт сверху, он внутри SCS. Часть вертикали.
- no shared business code — общий бизнес-код между SCS под запретом. Шаблоны, утилиты — можно, доменную логику — нет, иначе получишь скрытый coupling.
- async-интеграция по умолчанию — между SCS предпочтительно async или UI-композиция, sync-вызов в рантайме — крайняя мера.
- свой API опционален — SCS может вообще не иметь публичного API, если общается через UI и события.
- своя команда — один SCS принадлежит одной команде. Conway's Law не борешь, а используешь.
Note
Формулировки и количество принципов на сайте со временем правили. Держись смысла, а не точного числа: автономия деплоя, своя БД, UI внутри, минимум синхронной связи.
Чем отличается от микросервисов
Самая частая ошибка — считать SCS «микросервисом с UI». Разница в зерне и в способе связи.
| Признак | Microservices | SCS |
|---|---|---|
| Зерно | мелкое, много сервисов | крупное, единицы систем |
| UI | обычно отдельный фронт | UI внутри, обязателен |
| Связь в рантайме | часто sync RPC/HTTP | async или UI-композиция, sync избегают |
| Сколько на продукт | десятки-сотни | единицы (грубо 3-25) |
| Граница | технический сервис | бизнес-вертикаль end-to-end |
Чем отличается:
- SCS крупнее. Это не один эндпоинт, а целая автономная система. Внутри одного SCS может жить несколько микросервисов — масштаб другой.
- UI обязателен. У микросервиса UI обычно где-то снаружи, у SCS он часть вертикали.
- связь другая. Микросервисы спокойно ходят друг к другу sync в рантайме. SCS это осознанно не делает — иначе собрал distributed monolith (Communication & API Style), просто покрупнее.
Канон vs индустрия:
- в индустрии SCS часто зовут «вариантом микросервисов» или валят в одну кучу. На уровне маркетинга ок, по сути — другое зерно и другая модель интеграции.
- SCS можно читать как ответ на «микросервисы расплодились и связались синхронно намертво».
Топология
Каждый SCS — полная вертикаль. UI, логика, БД внутри. Снаружи — общий вход и тонкая интеграция.
browser
|
+--------v---------+
| routing / shell | тонкий слой: маршрутизация + UI-композиция
+--+----+------+---+
| | |
+-------v+ +v------+ +v--------+
| SCS A | | SCS B | | SCS C | каждый — отдельная команда
|--------| |-------| |---------|
| UI | | UI | | UI | UI внутри вертикали
| logic | | logic | | logic |
| DB | | DB | | DB | своя БД, без shared
+---+----+ +---+---+ +----+----+
| | |
+-----------+-----------+
|
async events / broker интеграция между SCS — async,
без sync-вызова чужой логики
Что важно на схеме:
- shell сверху тонкий. Он маршрутизирует и склеивает UI-фрагменты, но не держит бизнес-логику.
- стрелки между SCS идут через broker, не напрямую sync. Падение SCS B не валит SCS A.
- БД нарисованы внутри вертикалей не случайно — пересечения данных между ними нет.
UI-композиция — отдельная тема. Склеивать фронты можно по-разному:
- ссылки — самый дешёвый вариант. SCS A просто линкует на страницу SCS B. Ноль связности.
- server-side includes / Edge Side Includes — shell собирает страницу из HTML-фрагментов разных SCS.
- client-side композиция — фрагменты тянутся в браузере (web components, micro-frontends).
Плюсы
- автономия деплоя реальная, а не на словах. Своя БД и no shared code убирают скрытый coupling, из-за которого микросервисы часто выкатываются пачкой.
- отказоустойчивость по умолчанию. Нет sync-цепочек в рантайме — нет каскадных падений. Упал один SCS, остальные живут, максимум пропадёт фрагмент на странице.
- чистая граница владения. Один SCS — одна команда. Меньше кросс-командных согласований.
- технологическая свобода. Каждый SCS можно писать на своём стеке, раз нет общего кода и общей БД.
Минусы
- дублирование данных. Раз shared database нет, одни и те же данные лежат в нескольких SCS и синкаются через события. Eventual consistency и весь её хвост — твоя забота.
- UI-композиция — нетривиальная инженерия. Склеить фронты от разных команд в один цельный продукт без визуальных швов сложнее, чем кажется.
- крупное зерно режется редко. Нарезать продукт на правильные вертикали трудно. Ошибся с границей — переезд дорогой, дороже чем у мелкого сервиса.
- сквозной UX. Единый стиль, общая навигация, сквозная авторизация между автономными SCS требуют отдельной дисциплины и общих соглашений.
Когда подходит
- большой продукт с явными бизнес-областями, которые режутся на вертикали (портал, e-commerce, кабинет с разными доменами).
- несколько команд, и хочешь дать каждой полную автономию от UI до БД.
- интеграция между частями терпит async и eventual consistency — нет жёсткого требования «здесь и сейчас синхронно».
- хочешь плюсы микросервисной автономии, но боишься расплодить сотни мелких сервисов и связать их sync-вызовами намертво.
Когда не стоит
- маленькое приложение или одна команда — overhead вертикалей не окупится, начни с модульного монолита.
- предметка плохо режется на UI-вертикали (например, чистый backend без своего фронта — там SCS по определению не про это).
- между частями нужна сильная синхронная консистентность в рантайме — async-модель SCS будет мешать, а не помогать.