Дели код на слои - первый принцип. Полный список принципов здесь
Я еще не знаю задачу, но уже знаю, что в коде будет 3 слоя: приложение, инфраструктура, контроллеры. Отдельно конфигурация.
Этого достаточно, ведь у меня даже нет задачи. Я начну думать о моделях, адаптерах, объекта‑значениях, когда приступлю обдумыванию бизнес логики и реализации.
Слой приложения «главный». Он устанавливает правила и требования к интерфейсам других слоев. Он никому ничего не должен. Он не знает, как устроены другие слои, и что внутри, потому что он главный. Слой приложения не может требовать от других слоев навыков работы с закрытыми данными. Он не может передать объект с приватными свойствами в другой слой и хотеть, чтобы эти свойства были обработаны.
На фронте слой содержит код, который хранит и управляет состоянием независимо от отображения: сохраняет состояние между переходами по страницам, дает доступ к состоянию из разных шаблонов и т. п.
Для бэка это код, который описывает бизнес правила, отвечает за валидность и целостность данных во время обработки запроса. Такой код может быть реализован по разному:
— как модель, которые хранят состояние пока запрос обрабатывается;
— сервис без состояния
— функция с валидации целостности
Контроллеры — это все, что касается ввода и вывода.
Этот слой обязан знать, что нужно слою приложения, обязан это предоставить в нужном формате. Он не может ничего требовать от слоя приложения, обязан работать с тем, что отдал слой приложения.
На фронте в этот слой попадает всё, что касается взаимодействия с пользователем и обработки событий:
— шаблоны, стили, функции, которые готовят данные для отображения и обрабатывают ввод пользователя
— обработчики событий
— обработчики роутов, потому что роутинг — это интерфейс ввода данных.
— слушатели сокет соединений
На бэке это код, который принимает входящие запросы и отдает ответ, фоновые контроллеры:
— контроллеры gRPC, HTTP,
— слушатели очередей,
— конструкторы ответа, мапперы данных в нужный формат и т. п.
— описание протоколов.
Инфраструктура — помощник слоя приложения помогает получить, передать, сохранить информацию для выполнения бизнес логики.
Инфраструктура
— обязана работать с тем, что отдает слой приложения
— обязана вернуть данные в формате, который требует слой приложения.
Здесь лежат:
— клиенты к хранилищам, другим сервисам, кэшам, очередям и т. п.
— конструкторы запросов к БД, очередям или другим сервисам
— мапперы данных слоя приложения в нужный формат и обратно
Конфигурация — соединяет компоненты из всех слоев в единый модуль, микросервис, приложение. Конфигурация отвечает за передачу настроек и параметров из переменных окружения в компоненты.
Это может быть конфигурация di‑контейнера, место ручного создания компонен. Конфигурация может присутствовать как дополнительные нотации в UI компонентах. Фреймворки и языки имеют разные методы конфигурирования, поэтому конфигурация не является слоем или может быть не явной.
Слой приложения может отсутствовать. Тогда контроллеры и инфраструктура взаимодействуют напрямую. Чтобы сохранить порядок, нужно определить — кто главный. Главным лучше делать того, кто более стабилен.
На фронте слой контроллеров может часто меняться, контракт с бэком более стабилен — инфраструктура главная.
На бэке формат хранения может измениться после MVP, а контракт описан и стабилен — слой контроллеров главный.
Слои зависят друг от друга. Правила организации кода и внедрения зависимостей будут в отдельном посте.
