Юзкейсы, сценарии и интеракторы
Когда мы пишем наш код (программу, сервис, библиотеку), мы так или иначе анализируем зачем она нужна. У пользователей и заказчика продукта есть цели. Бизнес хочет получить прибыль, покупатель - получить товар, пользователь техподдержки - не показаться начальнику глупым, чтобы его не уволили. Есть цели более глобальные, такие как достижение благополучия, есть более конкретные подцели, как доставка товара на конкретный адрес.
Зачастую с системой взаимодействуют не только люди, поэтому часто используют более общий термин — актор.
Анализируя цели и потребности всех участников взаимодействия, мы приходим к формулированию требований, одной из форм которых являются use cases, которые и описывают взаимодействие некоторого актора с системой ради удовлетворения его целей. Каждый юзкейс - это текстовый документ, но они могут дополняться диаграммами. Юзкейсы могут включаться друг в друга или расширять. Например, "ввод адреса" может быть конкретным юзкейсом, использующимся как в юзкейсе "покупка товара", так и в юзкейсе "заказ уборки".
Юзкейс представляет собой некий набор шагов, при этом их можно разделить на основной сценарий и расширения. Cценарий - это последовательность шагов взаимодействия, в то время как юзкейс - набор возможных вариантов развития событий. Шаг в данном случае - ещё не конкретный api вызов, а просто логически выделенная операция, значимое намерение актора или реакция системы. Иногда оно может ссылаться и на другой юзкейс.
Переходя от этапа анализа к разработке, разбираясь с возможными юзкейсами и детализируя взаимодействие, мы уже можем зафиксировать конкретные детали реализации интерфейсов. Таким образом, одно логическое действие превращается в api вызовы, клики мышью и т.п. И в коде мы уже работаем с этими вызовами, хотя мы все ещё пишем программу, реализующую свою часть юзкейсов.
Обработка таких вызовов в коде обычно начинается с контроллера (адаптером между основной частью программы и фреймворком), а затем в реализацию прикладной части бизнес логики (часто используются термины "прикладной сервис" и "интерактор юзкейса"), а далее, возможно, в некие сущности и более универсальный части кода. Количество таких слоев зависит от конкретной методологии и сложности решаемых задач.
Хочу обратить внимание, что несмотря на то, что мы используем термин "интерактор юзкейса" - это лишь часть системы, реагирующая на действия актора. Сами юзкейсы при этом - более теоретическая часть, описывающая требования к нашему продукту как к черному ящику, но мы используем её для проектирования и организации наших интеракторов.
Пример юзкейсов.
Покупка товара
1. Пользователь выбирает товар из каталога
2. Пользователь указывает адрес
3. Пользователь оплачивает товар
Указание адреса
Основной сценарий
1. Пользователь вводит адрес.
2. Система показывает найденные варианты доставки.
3. Пользователь подтверждает выбранный вариант.
Расширение
3.а Пользователя не устраивают предложенные варианты
3.a.1 Пользователь повторяет ввод пока не будет найден подходящий вариант
При этом, если мы разрабатываем веб приложение, то могут быть такие api-вызовы как "GET /address-suggestions/" или "PUT /order/delivery". Для другого типа приложения, детали реализации взаимодействия так же будут отличаться
Дополнительные материалы:
• https://martinfowler.com/bliki/UseCasesAndStories.html
• https://alistaircockburn.com/Articles/Use-Case-Foundation-Ivar-Alistair
• https://habr.com/ru/articles/248063/
• https://blog.cleancoder.com/uncle-bob/2011/11/22/Clean-Architecture.html
Когда мы пишем наш код (программу, сервис, библиотеку), мы так или иначе анализируем зачем она нужна. У пользователей и заказчика продукта есть цели. Бизнес хочет получить прибыль, покупатель - получить товар, пользователь техподдержки - не показаться начальнику глупым, чтобы его не уволили. Есть цели более глобальные, такие как достижение благополучия, есть более конкретные подцели, как доставка товара на конкретный адрес.
Зачастую с системой взаимодействуют не только люди, поэтому часто используют более общий термин — актор.
Анализируя цели и потребности всех участников взаимодействия, мы приходим к формулированию требований, одной из форм которых являются use cases, которые и описывают взаимодействие некоторого актора с системой ради удовлетворения его целей. Каждый юзкейс - это текстовый документ, но они могут дополняться диаграммами. Юзкейсы могут включаться друг в друга или расширять. Например, "ввод адреса" может быть конкретным юзкейсом, использующимся как в юзкейсе "покупка товара", так и в юзкейсе "заказ уборки".
Юзкейс представляет собой некий набор шагов, при этом их можно разделить на основной сценарий и расширения. Cценарий - это последовательность шагов взаимодействия, в то время как юзкейс - набор возможных вариантов развития событий. Шаг в данном случае - ещё не конкретный api вызов, а просто логически выделенная операция, значимое намерение актора или реакция системы. Иногда оно может ссылаться и на другой юзкейс.
Переходя от этапа анализа к разработке, разбираясь с возможными юзкейсами и детализируя взаимодействие, мы уже можем зафиксировать конкретные детали реализации интерфейсов. Таким образом, одно логическое действие превращается в api вызовы, клики мышью и т.п. И в коде мы уже работаем с этими вызовами, хотя мы все ещё пишем программу, реализующую свою часть юзкейсов.
Обработка таких вызовов в коде обычно начинается с контроллера (адаптером между основной частью программы и фреймворком), а затем в реализацию прикладной части бизнес логики (часто используются термины "прикладной сервис" и "интерактор юзкейса"), а далее, возможно, в некие сущности и более универсальный части кода. Количество таких слоев зависит от конкретной методологии и сложности решаемых задач.
Хочу обратить внимание, что несмотря на то, что мы используем термин "интерактор юзкейса" - это лишь часть системы, реагирующая на действия актора. Сами юзкейсы при этом - более теоретическая часть, описывающая требования к нашему продукту как к черному ящику, но мы используем её для проектирования и организации наших интеракторов.
Пример юзкейсов.
Покупка товара
1. Пользователь выбирает товар из каталога
2. Пользователь указывает адрес
3. Пользователь оплачивает товар
Указание адреса
Основной сценарий
1. Пользователь вводит адрес.
2. Система показывает найденные варианты доставки.
3. Пользователь подтверждает выбранный вариант.
Расширение
3.а Пользователя не устраивают предложенные варианты
3.a.1 Пользователь повторяет ввод пока не будет найден подходящий вариант
При этом, если мы разрабатываем веб приложение, то могут быть такие api-вызовы как "GET /address-suggestions/" или "PUT /order/delivery". Для другого типа приложения, детали реализации взаимодействия так же будут отличаться
Дополнительные материалы:
• https://martinfowler.com/bliki/UseCasesAndStories.html
• https://alistaircockburn.com/Articles/Use-Case-Foundation-Ivar-Alistair
• https://habr.com/ru/articles/248063/
• https://blog.cleancoder.com/uncle-bob/2011/11/22/Clean-Architecture.html