Use Case with 2 ways for the same action

Question

Question 1: What is the correct way to build a Use Case (or more than one) with 2 ways to do the same action?

For example:

I have a 3 screens in

Answer 1

It appears that the two use cases seem to have identical end results that is "Create a Place with / without picture" with two ways - "With Camera and Location Service" vs "Manual Data Entry".

The "With Camera and Location Service" use case adds photo as well.

However, I am wondering if two ways of achieving the same result or identical result is considered single use case.

I would design the two as separate use cases if I can, otherwise I would make one as primary or default use case and other approach as an alternative to achieve the same / identical end result.

Use Case: Create Place

Basic flow: Use Camera and Location Service

1. User presses plus button.

2. App displays camera view.

3. User takes a picture.

4. App creates place with current location "and picture".

Alternate flow A: Use manual data entry

A.1. User “long press” on the map.

A.2. App drops a temporary pin and displays the place editing view.

A.3. User edits the place information and presses save button.

A. 4. App creates the place "without picture" and save it.

Does this make sense?

Updates with specific details

The View Controller responsible to deal with View in iOS, is in fact treated as View in VIPER. See the "View" paragraph. A UIViewController, or one of its subclasses, will implement the View protocol. Hence this controller is your View.

The idea is you need to isolate your Presenter from the knowledge of iOS View or iOS controller. It should deal with iOS specific view and controller via plain data structures like ViewModels. If you can do that, you have successfully isolated Presenter from iOS SDK specific dependencies and you can write and run TDD or Unit tests directly on your Presenters if you want.

However, more interestingly once you succeed in isolating Presenter from View and ViewController, you can isolate Interactor from Presenter easily. Presenter will have to pass data in the form that is acceptable to the Interactor. So Interactor does know nothing about Presenter. It's independent and you can this Interactor (Use case) in command-line, web or desktop-GUI app as easily.

I think there should be one Interactor per use case. If there are alternative flows to the use case, the interactor will have methods with those alternative data structures.

In your case the CreatePlaceInteractor will have two methods:

CreatePlaceWithManualDataEntryResult createPlaceWithManualDataEntry(CreatePlaceWithManualDataEntryRequest)

CreatePlaceWithCameraAndLocationServiceResult createPlaceWithCameraAndLocationService(CreatePlaceWithCameraAndLocationServiceRequest)

There will be three View/Presenters:

1. CreatePlaceChoicePresenter/View will capture user choice and send the request to the NavigationController or Wireframe as appropriate which will return new Presenter/View according to the user choice.

2. CreatePlaceWithManualDataEntryPresenter/View will create and convert CreatePlaceWithManualDataEntry ViewModel into CreatePlaceWithManualDataEntry Request and will receive CreatePlaceWithManualDataEntry Result and process accordingly to display the use case result on the view.

3. CreatePlaceWithCameraAndLocationServicePresenter/View will create and convert CreatePlaceWithCameraAndLocationService ViewModel into CreatePlaceWithCameraAndLocationService Request and will receive createPlaceWithCameraAndLocationService Result and process accordingly to display the use case result on the view.

Apologies for being verbose on request, resonse, viewmodels and method names.