Comments 29
Вам не кажется, что получилась слишком большая вложенность?
Store -> useCase -> repository -> apiService?
Не хватает вообще какого то резюме, что в итоге получили, удобство поддержки, там, или простоту.
А ещё
new TodoModel().from(json)Выглядит странно, имхо. Либо уж через конструктор, либо статический метод fromJson кажется было бы лучше
Наоборот такая вложенность гарантирует нам то что каждый слой сервиса будет работать атомарно не нарушая принцип работы другого сервиса
насчет TodoModel соглашусь, ее можно имплементировать разной вариацией, сразу из под коробки можно вызывать TodoModel.fromJSON(json)
Наоборот такая вложенность гарантирует нам то что каждый слой сервиса будет работать атомарно не нарушая принцип работы другого сервиса
Непонятно, если честно. Есщи б у меня репа сразу запрос слала, то что бы я проиграл?
Не зря говорят, что любую проблему может решить добавлением слоя абстракции, кроме проблемы большого количества слоёв. На практике, при изменении придётся менять сразу все слои, что в поддержке неудобно. По моему опыту.
Так что кажется наоборот, такая вложенность гарантирует, что слои атомарными никак не будут
слой репозиторий - эта обащение непосредственно к нашей апи application. тем самым не нарушая само обращение к бд. Ведь представьте что вам завтра нужно будет поменять холодильник, но привычка как брать с холодильника у вас осталось
А есть нормальные аргументы, а не холодильники?
Не совсем понимаю пока логики ваших слоёв и их зоны ответственности
Ещё вы упомянули DDD, а где у вас доменная логика будет?
я имею что дополнительный слой абстракции нужен для того чтобы отделить работу с бд и работа с апи, ведь на уровне репозиторий наша задача просто брать данные и обрабатывать их в случае ошибка возвращать пользователю, при этом не нарушая саму концепцию data layer
А может быть для разделения работы с апи и с бд просто нужны разные репозитории?
Я правильно понимаю, что репа у вас - это просто фасад?
да вы правильно подметили
Чувак, ты не выкупаешь прелести чистой архитектуры. Парень всё сделал правильно. Мы на Андроиде в лучших практиках так и поступаем.
Вложенность тебе не нравится? Ну положи весь код доступа в базу данных прямо в метод который рисует текстовое поле, господи... Только никому не говори что это "чистая архитектура", а то смеяться будут.
У каждого слоя есть своё назначение, вот лично тебе какой слой не понятен? Если ты не ответишь на этот вопрос, минус объективным быть не может, лучше извинить и поставь ему плюсы.
Не кажется, это слоистость архитектуры с возможностью менять каждый компонент. Обычно между юзкейсом и репой бывают еще сервисные слои от БЛ до всевозможных компонент. Для того что бы это понимать, вы должны изучить что такое ООП и как с ним работать, а не только что есть класс и у него есть методы (как 90-95% тут живущих). С apiService пока только не очень понял, ощущение что то, что обычно задают как тип репозитория RemoteRepository, FileRepository, SQLRepository, StubRepository и т.п. Автор молодец что смог разобрать это самостоятельно, учитывая какое сопротивление и бурю непонимания от "коллег" он испытывает.
Вас в этой "чистой архитектуре" не смущает, что при каждом ремаунте вьюшки происходит загрузка всех задач?
Чистая архитектура это просто способ хранения файлов проекта. Ну и понимания какие файлы должны от каких зависеть. Не более.
К реализации бизнес логики (которая содержит упомянутую тобой проблему) это не относится
Вы только на собеседовании это не говорите, а то выше джуна не возьмут.
А ты за меня не переживай, за себя лучше. Ибо для тебя реализация и проектирование понятия тождественные, тебе чистая архитектура виновата в ремаунтах xD
И этот твой бредовый коммент чудом получил плюсы, в то время как мой объективный тезис утонул в минусах. В целом это лишь показывает ценность оценок в этой ветке, не более. Хотя я всё же думал что русское сообщество будет адекватнее чем SO, но может это просто тред такой странный.
Чистая архитектура это просто способ хранения файлов проекта.
"Нет".
Способ хранения файлов проекта это способ хранения файлов проекта
Без объяснений выглядит как оверинжиниринг. Понятно, что сложно на TODO-примере объяснить зачем все эти файлы нужны, какую пользу даёт разделение на такое кол-во абстракций, но стоило попытаться.
Помнится по рукам били, когда бизнес логика была в слое презентации
Разделение на слои: DDD рекомендует разделение приложения на слои, включающие слой предметной области, слой приложения и слой представления.
Слой предметной области вижу (`domain`), слой представления тоже (`presentation`), а где слой приложения?
Пришёл бизнес аналитик от заказчика и сказал что у них в ToDo айтеме есть ссылка на джиру. Как в вашей архитектуре это добавить не меняя код "продукта"?
У меня предложение к автору: а теперь эту ToDo нужно расширить и ввести кнопки массового переключения: все отмеченные становятся не отмеченными и наоборот. При этом нужно отправить запрос на сервер об этом и результат обработать выводом с проверкой, что список действительно нужно перерисовать или показать тостер с сообщением, что данные на сервере не обновились (500 ошибка пришла). Как будет выглядеть такое решение с вашей структурой?
с FSD было бы лучше;)
Я вот читаю статью и думаю, что мне это все напоминает.
А Вы просто написали свой ангуляр на реакте.
Показаны структурные элементы, но тема не раскрыта абсолютно.
DDD, в первую очередь, ставит задачу изоляции смыслового ядра приложения в отдельном слое. Остальные элементы выделяются как удобная абстракция для использовании в слое предметной области. Ваше приложение работает с готовым решением, которое уже инкапсулирует всю бизнес-логику, связанную с предметной областью, для которой оно разрабатывается. Фронтенд — это лишь представление этой логики для пользователя. Вы не обосновали то, зачем вообще DDD нужен на фронтенде, как в вашем, так и в общем случае.
При добавлении элемента в список генерируется id. Вроде он должен быть случайным, но по факту он всегда будет равен 0.
Math.random() возвращает число в диапазоне от 0 до 1. То есть, это всегда будут числа типа 0.85930859583, 0.046633 и т.п.. Если у них вызвать метод x.toFixed(0), на выходе будет строка '0'.
Если уж охота сделать случайное целое число, результат Math.random() нужно умножить на что-то большое, а потом отбросить дробную часть, например используя Math.floor(x) или (x | 0) вместо Number(x.toFixed(0)).
Без негатива, тоже проходил этот путь.
Пришел к выводу, что чистая архитектура и в целом попытки адаптировать паттерны работы бека на фронте не заканчиваются хорошо и все это связано с тем, что одни паттерны придумывались для stateless систем, а у нас на фронте statefull, наличие состояния один из важнейших аспектов.
Такое количество абстракций ни к чему не приводит, тк все необходимые для отображения данные, точно так же будут гулять между слоями, а наличие такого количества абстракций может на более менее крупном проекте привести к огромному количеству бойлерплейт кода и при каждом чихе, внесение изменений кода во все слои, приведу примитивный пример.
У вас есть кнопка добавления элемента в Todo лист, а теперь бекенд сделал доработку и научился возвращать ошибку, вам чтобы отобразить ошибку рядом с кнопкой, необходимо внести изменения во все слои абстракции начиная от Service заканчивая самим компонентом View, который отображает данную ошибку.
А если какой то из слоев используется в другом месте системы? Вопрос конечно риторический, следить за всеми взаимосвязями очень тяжело.
В общем то говоря, слоенная архитектура не уменьшает зацепление системы, а скорее наоборот, способствует уменьшению связности и увеличению зацепления в statefull системах.
Если брать какие то statefull системы для аналогии, то это игры и там в очень редких случаях можно обнаружить именно слоенную архитектуру и все популярные в мире фронтенда паттерны вроде State, Rendering Cycle, Observer, Component, Dirty Flag, многие из этих паттернов популярны в разработке игр.
Так что могу только посоветовать, еще раз подумать над архитектурой, но в приоритет брать связность и зацепление, учитывая аспект наличия состояния на фронте, чтобы при внесении изменений в код, ненужно было перелопатить все слои абстракций, при этом попутно не отломал другие части приложения которые ее используют)
Как я добился чистой архитектуры на фронтенде