9

I'm developing an Android app whose architecture is based on Uncle's Bob Clean Architecture, and I've already implemented many of my UseCases/ Interactors without problems until now.

I have the following use case:

Search Room

  • Main Success Scenario

    1. System search for rooms based on given parameters
    2. System joins the user in the room
  • Extension

    1. Room Not Found

      a) System creates a new room based on given parameters

      b) System joins the user in the room

So, should I create a single interactor ( SearchOrCreateRoomAndJoin ) or create three interactors ( SearchRoom, CreateRoom, and JoinRoom ) and combine them according to my use case description?

Example:

 Room room = searchRoom.execute(roomOptions)

 if(room != null){
 
     joinRoom.execute(room)

 }else{

     Room room = createRoom.execute(roomOptions)
     
     joinRoom.execute(room)
}
regmoraes
  • 5,329
  • 3
  • 24
  • 33
  • 7
    The more I research about this topic, the more I think software is an art rather than an exact science... Have you found your answer? – Rodrigo Ruiz Jul 26 '16 at 20:14
  • @regmoraes You second is best. Why means 1.future you have chance some extra limitations like country,language or user type that time it's helpful 2. Sametime SearchRoom, CreateRoom and JoinRoom use to other screens also (Reusability) Ref:[link](https://speakerdeck.com/markomilos/clean-architecture-on-android) Religinal Timeline usecase slide – Rajesh Oct 11 '16 at 12:27
  • 2
    Hey, needed some clarity. Can only presenters execute Interactors or can one interactor execute another as per Clean Architecture? – Chris Rohit Brendan May 05 '17 at 11:08

2 Answers2

7

In my opinion, you should develop the three interactors in order to respect the Single Responsability Principle. If you do that, you increase the maintainability and reutilization of the code, because you could use these interactors separately in other scenarios.

antonicg
  • 934
  • 10
  • 24
  • yeah! writing those 3 interactors is a good way to start this but we should avoid `horizontal dependencies` when using `layered architecture`! if this code is at the `presentation` layer this is good but depending on multiple usecases isnt good though! we could abuse the benefit of `commands` and `events` on this case and just decouple those usecases from each other(and from the presenter)! our "entrypoint" usecase could just dispatch `commands`! the `command handlers` would be calling the desired usecases without coupling ur application services – gbrennon Jul 23 '21 at 09:05
0

Name the use-case as JoinRoom (only one use-case is enough here)

class JoinRoomUseCase( searchRepository : searchRoomRepository,
 createRoomRepository : CreateRoomRepository,
 joinRoomRepository : JoinRoomRepository){

            fun execute(param:Param){
                      if(searchRepository.findRoom){
                          joinRoomRepository.join()
                      }else{
                          val room = createRoomRepository.create()
                          room.join()
                      }
            }
}