Какие слои существуют в архитектуре приложений
Что проверяют
Знаете ли вы состав слоёв и понимаете ли правило направления зависимостей.
Как отвечать
Слоёв обычно три.
Слой представления. Экраны и держатели состояния. Отвечает за отображение и за реакцию на действия пользователя. Не содержит бизнес-правил и не знает, откуда пришли данные. Здесь живёт модель представления, которая держит состояние экрана и переживает поворот.
Слой предметной области. Сущности и сценарии использования. Чистый код без зависимостей от платформы: ни контекста, ни библиотек сети, ни базы. Здесь же объявлены интерфейсы репозиториев. Слой необязательный: для экрана, который просто показывает список, он превращается в обёртку в одну строку и только добавляет файлов.
Слой данных. Реализации репозиториев, источники данных: сеть, база, кэш, настройки. Репозиторий решает, откуда брать данные и как их согласовывать, а наружу отдаёт доменные модели. Здесь же живут объекты передачи данных и преобразователи в доменные модели.
Правило одно и главное: зависимости направлены внутрь. Представление знает домен, данные знают домен, домен не знает никого. Проверяется просто: если убрать всё, кроме доменного слоя, он должен собираться.
Отсюда следует ход, который и отличает понимающего: слой данных находится снаружи, а данные нужны сценарию внутри. Разрешается это инверсией зависимостей: интерфейс объявлен в домене, реализация в данных, связывает их граф внедрения зависимостей на уровне приложения. Стрелка компиляции идёт снаружи внутрь, а поток вызова наоборот.
Про модели: у слоёв они свои, между ними работают преобразователи. Выглядит избыточно ровно до момента, когда меняется формат ответа сервера, и правка остаётся внутри одного слоя.
Где спотыкаются
Тянут платформенные зависимости в доменный слой.
Отдают объекты сетевого формата прямо на экран.
Делают сценарий использования обёрткой в одну строку на каждом шагу.
Не могут объяснить, почему интерфейс репозитория лежит в домене.