Architecture

[looee1q]

Сейчас архитектура в проекте организована таким образом, что UseCase(ы) не выполняют свое предназначение (инкапсуляция бизнес логики), но при этом берут на себя работу, не связанную с бизнес логикой:

Если рассмотреть архитектуру на примере выполнения запоросов поиска из API, то получится следующая схема:

Даже если отстранится от того, что в настоящее время работа с сетью построена при помощи HttpURLConnection, общий замысел юзкейса сейчас заключается в выполнении абстрактного запроса в сеть (через репозиторий).
Смысл, который закладывается в понятие юзкейкса в общепринятой практике, заключается в инкапсуляции бизнес-логики, которая описывает, как пользователь взаимодействует с системой. Соответственно вся совокупность возможностей системы (в нашем случае - SDK) должна быть представлена в виде наборов юзейсов.

Я предлагаю перейти к следующей схеме, которая практически является типовой (или, как минимум, часто встречающейся):

Здесь каждый из юзкейсов выполняет свою единицу бизнес-логики.

[looee1q]

Данные обсуждения нацены на более предметный разговор по задаче:

• https://github.com/rees46/development/issues/1223

И в целом на обсуждение всех архитектурных решений в SDK.

[TorinAsakura]

Если коротко - то все задачи, которые тут создавались предыдущими людьми - это были попытки небольшими шажками прийти к гексагональной архитектуре. Наш СДК не самый простой и он будет расти, а потому тут необходимо чёткое разграничение ответственности, разделение на слои и доменизация. Про DDD ты можешь почитать на сайте майкрософта, читать книги не рекомендую от слова совсем.