Информация

Дата основания
2013
Местоположение
Россия
Сайт
koshelek.app
Численность
101–200 человек
Дата регистрации

Блог на Хабре

Обновить

Кошелёк Mobile Challenge: итоги конкурса и подробный разбор решений командой разработки

Блог компании CardsmobileПрограммированиеРазработка под iOSРазработка мобильных приложенийРазработка под Android
Рейтинг +10
Количество просмотров 987 Добавить в закладки 5 Читать комментарии 5
Комментарии 5
В одном из проектов CardsInteractor из domain-слоя обращается напрямую в CardsRepository из data-слоя, что нарушает последний принцип SOLID

Не мой проект, но немного не соглашусь. Вы там дальше предлагаете создавать лишний интерфейс. Но в мобильных клиент-сервервных приложениях так это и останется висеть навсегда. В книге же дядя Боб описывает, что бизнес сущности(в этом случае интеракторы) не должны зависеть от нижних слоёв. Но для мобилок это не существенно. Приложения — это сателлит к серверу. Никто не меняет апи/сервер на лету у приложения, проще написать приложение под новый сервер..

Не видел код, но подозреваю, что если мы напрямую обращаемся из domain-слоя в data-слой, значит оба слоя находятся в одном gradle-модуле или domain-модуль имеет в зависимостях data-модуль, что означает, что clean architecture уже сломано.
domain (как внутренний слой) не должен знать о реализации репозитория, которая находится в верхнем слое. он всего лишь описывает интерфейс и ждет, что реализацию ему предоставят извне (через DI).

Именно так. А делать это на мобилках для того чтобы соблюсти последнюю буковку в soliD между слоями — супер избыточно, имхо.

Это почему вдруг избыточно?
Чем приложения на девайсах отличаются от приложений на десктопе, бэке, вэбе? В некоторых клиентских приложениях может быть кода в несколько раз больше, чем на сервере, и это не значит, что надо сваливать все в одну кучу и забивать на архитектуру. Сегодня в приложении 2-3 экрана, которые пилит 1 разработчик, а завтра там 30-50 экранов, которые пилит уже целая команда. И чем дальше в лес…
Конкретно в этом случае мы жестко связали два слоя (что потенциально развяжет руки джунам-миддлам в команде, которые войдут во вкус и продолжат напрямую юзать репозиторий), и захардкодили репозиторий (что потенциально сделало его non-testable).
Может и тесты писать не нужно? И вообще все в одну активити, раз приложение такая мелкая сошка — сателлит к серверу.

Ну смотрите. Сможет приложение Кошелёк работать с бэком, скажем, который для Кинопоиска — просто так нет. Но если идти по правилам Clean и не связывать слои и потом сделать адаптер бека Кинопоиска к бизнес сущностям Кошелька, то в целом наверное можно. Но зачем?!:) Но именно это и описывает и для этого и предназначается, то, о чём говорит в своей книге дядюшка Боб.
Просто я этим и занимаюсь. У нас видео приложение с нашей бизнес-логикой и мы хотим, чтобы оно умело работать с разными серверам вообще от разных систем с разным апи. И это куча работы и связок.
Для чего это обычным приложениям?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.