В чем разница между presenter'ом и interactor'ом в чистой архитектуре?

#архитектура

Разбираюсь с чистой архитектурой. Не доходит один момент: на сколько я понимаю цепочка
работает примерно так:


  controller <-> persenter <-> interactor <-> repository


Если рассмотреть это на примере метода, то получается, что контроллер вызывает метод
presenter->getBooks(), далее презентер вызывает интерактор: interactor->getBooks()
и только потом происходит обращение к репозиторию. 

При этом, presenter и interactor просто вызывают один и тот же метод. Так в чем же
их разница?

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

Ответы

Ответ 1

Clean Architecture подразумевает, что код разделен на 4 уровня со следующим правилом
зависимости: внутренний уровень не должен зависеть от каких-либо внешних уровней. Это
означает, что зависимости должны указываться внутри каждого уровня, чтобы не было зависимостей
между уровнями (слоями).


Соответственно сущности Presenter и Interactor(Use Cases) лежат на разных уровнях
и несут разную смысловую и функциональную нагрузку. 

Presenter обрабатывает события от пользовательского интерфейса (UI) и работают как
callbaсk-и из внутренних уровней (Interactors). Presenters являются легко тестируемыми
объектами и их основная задача -  получить данные от приложения и преобразовать их
так, чтобы Представление (View) могло просто переместить их на экран. 

Interactor же фактически содержит бизнес-логику приложения (проверка каких либо условий
и обработка данных). Они работают в фоновом режиме и передают события и данные верхнему
уровню (Presenters) c помощью callbaсk-ов. Это полностью соответствует принципу единственной
ответственности, который гласит, что каждый объект должен иметь одну ответственность
и эта ответственность должна быть полностью инкапсулирована в класс. Все его поведения
должны быть направлены исключительно на обеспечение этой ответственности.

Например над проектом работает несколько команд, каждая из которых разрабатывает
код на определенных слоях. Когда разработчики компонента Presenter-а поменяют что-то
в коде и захотят протестировать его,
им просто нужно собрать свою версию Presenter-а с версиями компонентов
Interactors и Entities, используемыми в данный момент. Никакой другой компонент в
системе им не потребуется для этого. Это означает, что разработчикам Presenters не
придется прилагать значительных усилий для подготовки к тестированию и им достаточно
учесть небольшое количество переменных. Вышеописанный пример легко проследить на диаграмме
компонентов, представленной ниже.


Очень важно заметить, что в такой диаграмме компонентов есть особенность: с какого
бы компонента вы ни начали, вы не сможете пройти по связям-зависимостям и вернуться
обратно в этот же компонент. Эта структура не имеет циклов - то есть это ациклический
ориентированный граф.