Пример Android приложения с Clean Architecture 

Благодарю, видео будут :)

ты же вообще не понимаешь ничего в программировании , пошел вон, это не для тебя

@@Ditto_Head Вот пожалуйста - скуф буллит порядочного человека, позор тебе. А я напоминаю, что на этом канале против буллинга, хуюлинга и борисаюлинга

спасибо за комментарий :) "использование модельки из дата слоя в юзкейсе весь этот замысел портит" - каким образом? Если домейн слой знает про существование дата слоя, тем самым он знает про его сущности "бизнес-логика должна быть в дата слое, а в домене находятся просто дополнительные функции, но это неверно. в домене как раз таки и должна находиться бизнес-логика. домен - центр всей системы" - домейн это необязательный слой, если его не будет в проекте, то где будет бизнес логика?) гуглы сами у себя в статье пишут, что домейн слой способствует переиспользованию шаблонной логики. юзкейс так же может включать в себя юзкейсы ) по сути да, проект в видео это абстракция чистой архитектуры. писать код нужно нужно головой )

​@@androidtavern у вас домен общается с датой через интерфейс репозитория, который является частью домена, а дата с доменом - путем реализации этого интерфеса. из-за модельки получается, что дата зависит от домена потому что знает о интерфейсе репозитория, а домен зависит от даты потому что знает о модельке. получается циклическая зависимость. то есть вы не можете без изменений в коде поместить домен и дату в разные gradle-модули. да, домен - необязательный слой, но он у вас есть и в нем стоит соблюдать правил зависимостей. представьте, что у вас поменялась схема json, и вместо поля id прилетает $id. и вам придется подсказать gson'у название поля, добавлением анотации SerializedName. и теперь ваш домен знает о том, что данные приходят в формате json, а это уже и зависимость от библиотеки, и детали реализации, которые должны быть в слое с фреймворками и библиотеками. прошу прощения, если надоедаю, просто хочу помочь (или понять, что я неправ), так как формат мне понравился и я все еще жду новых видео )

@@nevdatny а, понял. спасибо за замечание. по естеству конечно интерфейс из домейна в дата слое портит малину. я не помню почему так сделал, но оно выглядит неправильным и нелогичным. Вы абсолютно правы в этом замечании. только с json не совсем понял, домейн ничего все равно знать не будет о схеме, ведь наша область видимости объект а не его данные. к примеру если мы и добавим аннотацию, то во всем проекте ничего не изменится, кроме самого класса объекта

@@androidtavern попробуйте поместить каждый слой в отдельный модуль. тогда все станет очевидно.

Domain знает только о домене, и сущности в домене должны быть только доменные. Дата может иметь свои сущности, зависящие от датасорсов, но в имплементации репозов обязательно нужно мапить в доменные сущности, так как репозы в интерфейсах должны отдавать только доменные сущности. Тоже самое и эксепшены. Необходимо мапить все нетворк/парсинг/датабейс эксепшены в доменные кастомные эксепшены, чтобы Ui слой получал только доменные сущности и никаких эксепшенов слоя дата.

И Вам спасибо за комментарий! Рад помочь :)

Не мапить domain в UI. Использовать только domain model. Ну, а если совсем большой json мапить что надо. Мне кажется отдельная UI model нужна редко

признаюсь не сталкивался с проблемами с производительностью в целом, по этому не могу ответить как можно избежать. самому стало интересно, пошел гуглить :)

@@androidtavern к какому выводу в итоге пришли ? :) интересно же :)

@@PavelStr-x5w Честно, не разбирался, но перечитав сообщение могу сказать что это очень плохо, если будет большой джейсон парсится. Есть решение как пагинация

в целом чистая архитектура выглядит как луковица со слоями, или вы можете вкратце объяснить примером как вы видите чистый код?

ну, пока самое хорошее объяснение я нашел в этом видео: "Clean Architecture. Простое объяснение за 10 минут" от канала StringConcat@@androidtavern

​@@androidtavernмне лично зашло объяснение Тимофея Коваленко Только тогда паззл сложился и пришло понимание, зачем конкретно это нужно Вот например я пока не очень понимаю, зачем нам нужны мапперы, особенно на начальном этапе развития проекта. Преобразования можно делать в репозитории. А если будет видно, что есть какая-то часть которая повторяется, выделить для нее маппер

это хорошо смотреть разную подачу материала с разных источников :)@@IhorBilous-z5x

преобразовывать в репозитории из дата сущности в юай? дата слой не знает про верхнии слои так сказать, так что это плохой подход в целом никто не заставляет вас иметь разные сущности в разных слоях, на видео пример чистой архитектуры как это по идее выглядит. но я не давал и не даю гарант что это верное решение для реализации чистой архитектуры. как по мне, нужно исходить из ситуации (как вы заметили).@@sovaz1997

давайте так, представим цепочку: UI >> DOMAIN >> DATA получается что юай слой зависит от домейн, а домейн в это время от дата слоя. дата возвращает нам результат требования, в виде сущности, которую домейн слой принимает и может обернуть в свою сущность и вернуть на юай. юай не знает про дата слой (если существует домейн), и идет к домейну с требованиям: мне нужны данные для отображения домейн мол - ок, сейчас будут и сам идет к дата слою за данными. юай слой ждет и не знает и не хочет знать откуда домейн слой возьмет эти данные. теперь мы понимаем что юай слой не знает про дата слой, но знает про домейн. мы таким образом не сможем вернуть юай слою сущность дата слоя. так как дата слоя не существует для юая. но он знает про домейн и сможет работать с его сущностями.

@@androidtavern но всё-таки цель архитектуры же сделать домен независимым) Домен никак не относится к данным (к способу их получения). Репозитории используются как раз, чтобы убрать зависимость от даты Или я Вас неправильно понял?

Домен независимый слой от юай, но зависим от даты. По другому никак не получается (см. док. от гуглов по чистой архитектуры). Домен это прослойка между юай и датой, если на то требуется в архитектуры, как доп. условие для бизнес логики Репозитории относятся к дате, верно, но их задача это хендлить бизнес логику (в себя принимает источники данных/другие репозитории с которыми взаимодействует)@@sovaz1997

​@@androidtavern так по сути Вам нужно мапить данные в репозитории и все Вроде как будет полная отвязка от даты в таком случае. А сейчас получается, что Вы на уровне домена мапите данные маппером. UseCase ничего не должен знать о том, как выглядят реальные данные - взаимодействие должно идти с моделями уровня домена

@@sovaz1997 вот именно. Домен ничего не знает о дата моделях, только доменные сущности. И мапинг должен быть либо в дата либо в презентейшен слоях.

Ведь она нужна вроде как для запросов в сеть

если стандартно, то ваша многопоточность должна быть привязана к жизненному циклу экрана. соответственно это будет в viewmodel/presenter. задачи разные бывают, и в зависимости от них многопоточность может быть и в другом месте.

Конечно

@@androidtavern нет. Дата слой отвечает за доступ к данным приложения. Если мы говорим о клин архитектуре. Дата слой отвечает на вопрос "где взять данные?", домен слой отвечает на вопрос "что с этими данными делает наше приложение". Бизнес логики не должно быть в дата слое в клине.

@@MrZiko1975 Вы говорите про data source. Не забывайте что data слой имеет так же repository. Так же если нету промежуточного слоя domain, то где будет бизнес логика?..

Дата слой - имплементит репозитория. Определяет репозитория - домен слой. Домен слой ничего не знает про дата слой и кто и как его имплементит. Этот принцип хорошо видно на уровне модулей и зависимости модулей. Домен градл не содержит других implementation, один чистый котлин. Дата модуль как раз содержит implementation (":domain")

Привет Видео будут после нового года, возможно раньше получится :)

@@androidtavern очень жду, ты красава

@@halu055 брат, альхамдуллиа1х у тебя все получится на твоем пути

Хотел сделать атмосфернее видео, но учту, спасибо