Хочется чтобы UseCase был на высоком уровне абстракции. Сценарий использования системы с пользовательской точки зрения. Нечто позволяющее совершить осмысленное бизнес-действие.
Хочется избежать, чтобы детали технической реализации влияли на дизайн этих классов. В сколько этапов и как сценарий осуществляется - синхронно, асинхронно, не должно влиять на нейминг и композицию, имхо.
Хочется решить проблему: как идеи формулируемые в пользовательских историях (я как пользователь, хочу сделать что-то, чтобы получить результат) транслировать в сценарии использования. Чтобы коммуникация между бизнесом и разработкой была с минимумом искажений на самом высоком уровнем постановки (для заказчика) и абстракций (для исполнителя) (то что называется "кричащая архитектура" у Дяди Боба (https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html)).
В простейшем случае 1:1, в случае вариативности сценария - 1 история (по вариантах в критериях приёмки) распадается на несколько Use Case. В многоролевой системе одна фича содержит несколько пользовательских историй для задействованных ролей и важно на этому уровне выдерживать правильные абстракции от них.
Примеры:
1. Feature: регистрация пользователя.
User Stories:
Я как клиент, хочу зарегистрироваться в ЛК, чтобы делать заказы.
Use Case:
Варианты расположения в структуре проекта:
Domain\Client\UseCase\ClientRegistrationDomain\Client\Registration\UseCase\Registration- если делать разделение на Features.
Соответствие user story:use case 1:1.
2. Feature: создание заказов через Telegram Bot.
User Stories:
2.1. Я как клиент, хочу оставлять заказ через telegram bot, почему?. 2.2. Я как менеджер, хочу получать уведомления о заказах оставленных в telegram bot, чтобы брать их в работу. 2.3. Я как ген.дир. хочу автоматизировать переписку и создание заказов в telegram bot, чтобы сэкономить на менеджерах.
Use Cases:
Domain\Orders\UseCase\TelegramBot\ClientRegistratorDomain\Orders\UseCase\TelegramBot\OrderRegistratorDomain\Orders\UseCase\TelegramBot\ManagerNotifier