Clean Architecture

Clean Architecture is a architectural pattern that allows high level of separation of concern by separation of layers. Its basically a group of best practices that allows us to write effective code.

What are the benefits of Clean Architecture?

1. Framework Independent:
   The core of application is separated from the framework specific components. The frameworks are used as plugins. Frameworks are considered services. That is to say, we can focus on the business logic (what makes our app different from others) being agnostic to the outside world so that you have the possibility of choosing whatever framework you want.
2. Testable:
   Our code becomes extremely easy to test because our domain logic is decoupled from the implementations details of the outside world. That results in quicker tests since we are able to validate our system in isolation. All we pass to the application core business logic are the request model and the interactors provide us with the result model after communicating with the entities. We can test those models in isolation without even starting the application or running the server up.
3. Independent of UI:
   The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
4. Independent of Database:
   You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
5. Independent of any external agency:
   In fact your business rules simply don’t know anything at all about the outside world. The business rules are not dependent on the plugins or services. For example: You are using Android Studio. Consider it as the business rules. And you add a plugin to your studio, lets say Material Design Icon Generator. The android studio does not anything about the plugin you added. You can add any other plugin. The plugins will simply extend the functionality of the business rules nothing more.

Now, let me share something that Uncle Bob mentioned in his talk in NDC2013.

When we look at most of the application, this is what we commonly see:

android packaging

Can we guess what this application is composed of and what this application does by looking at this? No. At the top level this applications packaging is telling we what its components are not what it actually is. Lets take a look at google note taking application for android testing. Its also in MVP:

Which one is more informative? I bet its the bottom one. By just looking at the folder structure, we can guess what the application can do and what its about. May be we can add note, view note detail and also see the statistics on the notes that we have written. Its more informative. We all know that a application contains activities, fragments, models, widgets and all. But it isn’t giving us the general purpose of the application. You decide which suits you the most.

Now, lets move on to our Clean Architecture concept.

Lets start with use cases.

Use Cases:

Use cases drives the architecture. Use case may be any action that the user can perform. For example, use cases can be part of order processing system like Create Order.

It describes how system processes the action and what data is returned. Use cases contains the business rules related to a particular action a user can perform. Lets take a look at a Create Order use case.

So, this contains what data it need, and the actions it can perform for this particular case. The actions it performs are framework independent. The use case can be used for an android application or for an ruby application. Its the same for both. For both framework, what Create Order case should do is take those data and apply those actions on them.

Interactor:

Use cases an be broken down to objects. Take the use case and put it into objects and its the interactor. It can be called the use case objects as well. Its easier to understand when we call it use case objects.Business Rules:

There are two types of business rules. Keeping them separate is the core for a good architecture.

1. One is application specific business rules. Like the rules incorporated by the interactor. These are the rules that are specific to the application being executed.
2. The other one is application independent. The logic that can be used on any application.

The second business rules are called entities. Our application can have many entities. Like for order creation there can be a Customer Entity, Product Entity and Order Entity. The Interactor controls all of these entities in the context of creating an order.

The entities can have data and can have methods as well.

Boundary

The interactor interacts with other components of the application through the boundaries. The boundaries are basically the interfaces.

The interactor implements one of the interface. This is the input boundary. All the data gets in through this boundary. The other one is the output boundary. Data goes out through this boundary.

Request Model:

Lets assume that the user inputs some data and requests a certain use case action. The request of the use gets passed to the boundaries via some delivery mechanism. We don’t case about what the delivery mechanism is, it just passes the request model to the interactor corresponding to the user action requested.

User model can be a data structure or a simple java object or may be arguments to a method. These are the data that the interactor acts upon. There are the data interactor performs the actions on.

Request model gets request model and guesses that it has to do some work. Interactor controls the dance of the entities. Its the choreographer. It uses data model to start calling the methods in the entities or may be access the variables on the entity.

Result Model:

Once the job is done, the interactor pulls the data out and constructs a data structure or a model called the result model. Result model is send back to the boundary and finally to the user.

Can this be tested?

Yes. Without running the application or web server. You input the request model and you get the result model. You can test all the business rules without running the application or the web server.

Now, lets insert MVP to this architecture.

MVP:

The job of the presenter is to take the response model and turn it into yet another data model.

Can presenter be tested?

Yes. Without running the application.

View Model:

The model is still independent of the view. It can be web, it can be android but if you put this data structure to a web page, there would be a field for every element . If you have buttons on the web page that have names, this model has strings with those names, There are Boolean that tells the state of the buttons.

View just presents it. There may be if statements. There may be the codes that doesn’t need to be tested. You can test it but there is no test worthy codes here.

The line between the components above is a boundary. This is a component boundary. Across the boundary, any dependency must point inwards. The inner components should not have any reference to the outer components.

So this is all about clean architecture. Happy coding.

And here a video on Clean Architecture by Uncle Bob Martin himself.