[BOC-0003] Project architecture, design and structure

[jonnyPap]

This issue is created to open a conversation about the architecture and design of this project. As this starts as a training, "best practices", new technologies project some basic structuring decisions that need to be made (sure that's something that might, can, and probably will change in the future).

As a footing for the discussion I would like to suggest:

• A layered (domain-data-presentation -> not strict but to be decided) modularization, of course following the clean architecture paradigms and principles. Also any abstract, reusable feature or tool can be an independent module of its own to serve reusability in different projects.

• About the design pattern used maybe MVVM or MVI or a little bit of both. (Mr. Zukanovs suggestions are always welcome here)

Let the discussion begin!

[george-theocharis]

What I would propose is to have a package by feature architecture where each feature has its sub-packages that follow the clean architecture paradigm. As for the architectural pattern to follow, a unidirectional MVI flow taking advantage of view models and coroutines would be enough in my opinion.

[george-theocharis]

Used the issue to import some basic libraries instead of the architecture. We need to start defining features to start contemplating architecture.

What I am thinking though is the below:

• Create a feature screen class with state, events and effects like:

  class CounterScreen {
  
      data class State(val counter: Int)
  
     sealed class Events {
  
          object IncrementClicked: Events()
         object DecrementClicked: Events()
  
      }
  }

• Create a flow of the click listeners on the screen. In the previous example there would be 2 buttons the + and - signs thus their click listener would be:

  callbackFlow {
  this@incrementButton.setOnClickListener {
      this.offer(CounterScreen.Events.IncrementClicked())
  }
  awaitClose { this@clicks.setOnClickListener(null) }
  }

• Finally the view model would listen to that flow and with a when route the correct event to the correct use case.

• The use cases will produce a result or an error which a reducer will use to produce a new state.

• The new state will be data class with the correct values for that state that its being observed from the view model.

How does that sounds to you? I am not perfectly comfortable with flows so remains to be seen if the view model can observe such flow from the ui or it will lead to a memory leak.

[jonnyPap]

As a follow up to your proposals I run into an article that utilizes the MVI-MVVM architecture we are looking to implement and the setup proposed there seems very promising.

Take a look here and let me know what you think.