В своем блоге, в посте про Clean Architecture Роберт Мартин как один из элементов архитектуры приложения выделяет use cases или interactors предназначение которых описывается следующим образом:
These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case.
Не сразу все понятно из этого описания, но основную идею можно уловить — получаем некие данные и передаем их сущностям предметной области.
А вот еще одна цитата, на этот раз из книги Эрика Эванса «Предметно ориентированное проектирование» (Domain-Driven Design):
Application Layer: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
Тут идет речь о слое приложения (Application Layer), который если вдуматься выполняет сходные функции со слоем use cases. В этом слое выполяняется работа по координированию взаимодействия доменных объектов или сущностей. И ведь действительно, где-то должно происходить обращение к репозиториям и создание сущностей. Кроме того как-то должно происходить взаимодействие с внешними сервисами и системами, обращаться к которым из доменных объектов не очень правильно, так как нарушает принцип чистоты модели предметной области.
Так вот, слой приложения или вариантов использования получает запрос на выполение какого либо действия и далее передает параметры этого запроса сущностям предметной области, почле чего возвращает результат их работы. Также этот слой запрашивает сущности у репозитория, инициирует сохранения состояния и обеспечивает взаимодействие с другими сервисами и адаптерами.
Use Cases vs Application Services
Фактически есть два варианта слоя приложения и вариантов использования:
- Реализация каждого варианта использования как отдельного класса (Interactor)
- Реализация набора вариантов использования как методов класса сервиса приложения (Application Service)
Как вы понимаете, каждый из этих методов имеет сови достоинства и недостатки и я не хотел бы углубляться сейчас в них. Я предпочитаю второй вариант, так как он менее многословный и более явно описывает ваши намерения с точки зрения ООП, ведь все что вы хотите — выполнить некоторе действие, а значит вызвать метод некоторого класса. И в конце концов, всегда можно сделать сервис с одним методом.