Представьте, что вы открыли пиццерию. В ней все устроено четко:

Гость → Официант → Повар → Кладовая

Гость говорит только с официантом. Официант передает заказ повару. Повар берет продукты из кладовой. Никто не лезет не в свое дело - гость не бегает на кухню, а повар не спрашивает у посетителя, где лежит мука.

Это и есть многоуровневая архитектура в чистом виде.  Каждый этаж знает только о соседе снизу.

В архитектуре это выглядит так: Гость - Presentation (интерфейс, API Gateway) Официант - Application (use cases, сценарии) Повар - Domain (бизнес-правила) Кладовая - Persistence (база данных)

Топология

Топология - это план того, кто с кем разговаривает. Есть три правила: 1. Уровень N зависит только от уровня N−1. Обратные вызовы запрещены - повар не может крикнуть официанту “принеси мне заказ”. 2. Нельзя пропускать уровни. Гость не может напрямую обратиться к кладовой. 3. Направление всегда сверху вниз.

Есть два варианта реализации.  1. Закрытый - каждый уровень общается только с соседом.  2. Открытый - можно прыгать через уровень. На практике почти всегда получается гибрид: где-то строго по соседям, где-то делают исключение, чтобы не плодить лишние прослойки.

Изоляция

Главная ценность этой схемы - изоляция. Меняете повара? Официанту всt равно, гость вообще не заметит. То же в коде: доработали бизнес-логику - не пришлось трогать UI и БД.

Достигается это двумя механизмами: 1. Контракты (интерфейсы). Это принцип инверсии зависимостей - уровни договариваются “что” делать, но не “как”. Повар не обязан быть конкретным человеком, важно, что он умеет готовить. 2. DTO между уровнями. Отдельные объекты для передачи данных, чтобы доменная модель не расползалась по всему приложению и не утекала в UI. Гость видит меню, а не внутреннюю бухгалтерию кухни.

Изоляция бывает логической (модули в одном процессе) и физической (разные серверы, общение через HTTP или gRPC). Первая проще, вторая надежнее, но дороже.

Можно добавлять уровни

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

В коде точно так же: кэш между Domain и Persistence - ускоряет чтение API Gateway поверх Presentation - единая точка входа Anti-Corruption Layer - прослойка для работы с внешними API, чтобы их модели не протекали в вашу систему.

Когда это стоит выбирать

Да, если: - бизнес-логика сложная и ее много - несколько каналов: web, mobile, API - строгие требования к безопасности - проект живет долго - есть нормативы (SOX, PCI DSS, ФЗ-152)

Нет, если: - это MVP или прототип - жесткие требования к задержкам (HFT, real-time) - простой CRUD - там хватит Active Record или Transaction Script, не усложняйте.

Итог

Многоуровневая архитектура - это деление системы на “этажи” с четкими контрактами между ними. Каждый знает только свое дело и общается с соседом.

В результате код становится понятным, безопасным и легким в изменениях. А главное - когда через полгода придется что-то переделать, вы не будете разбирать все приложение по кирпичикам.

Пиццерия работает именно так - и не жалуется.

#архитектура #разработка #softwarearchitecture #программирование #it