Обычно выделяют представление или транспортный слой, прикладные сценарии, бизнес-правила и инфраструктуру с доступом к данным. В простом приложении некоторые слои объединяют. Внутри процесса они общаются вызовами функций и методов через согласованные интерфейсы; между процессами возможны HTTP, RPC и сообщения. Логические слои не равны физическим уровням развёртывания: несколько слоёв могут работать в одном backend-процессе.
Какие слои есть в приложении и как они взаимодействуют?
Разделение интерфейса, сценариев, бизнес-правил и инфраструктуры. Почему логический слой не обязательно является отдельным сервисом.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Я разделяю приложение по ответственности, а не только на frontend и backend. Удобная исходная модель включает несколько логических слоёв:
- Представление и транспорт: пользовательский интерфейс, HTTP-контроллеры или обработчики сообщений. Они разбирают запрос, проверяют его форму и преобразуют ответ в нужный протокол.
- Прикладной слой: реализует сценарии, например оформление заказа; координирует бизнес-операции, доступ к данным и внешние взаимодействия.
- Доменный слой: содержит бизнес-правила и ограничения, которые не должны зависеть от HTTP или конкретной базы данных.
- Инфраструктура и доступ к данным: реализуют хранение, отправку сообщений, интеграции и другие технические механизмы.
Это не обязательные четыре каталога или сервиса. В небольшом приложении прикладную и доменную логику можно объединить; отдельные слои оправданы, когда помогают управлять изменениями и тестировать правила. Backend обычно включает несколько таких ответственностей, а не представляет собой один неделимый слой.
Внутри одного процесса общение обычно происходит через вызовы функций и методов. Например, контроллер передаёт команду прикладному сценарию, тот применяет бизнес-правила и вызывает интерфейс репозитория, а инфраструктурная реализация выполняет запрос к БД. Наружу возвращается согласованный результат или DTO; детали ORM и сетевых ошибок не должны бесконтрольно проникать во все уровни.
REST, gRPC и очереди нужны при соответствующих межпроцессных границах, а не потому, что в коде появился очередной слой. Логические слои могут находиться в одном процессе; физические уровни развёртывания — отдельный вопрос. Microsoft: layers и tiers.
Направление вызовов также не всегда совпадает с зависимостями исходного кода: бизнес-логика может зависеть от интерфейса, а инфраструктура — реализовывать его. Важны явные контракты, правила ошибок и границы транзакций, а не максимальное число абстракций. Пример архитектуры с инверсией зависимостей.