3 Clean Architecture

Clean Architecture describes another more general software architecture with the objective of achieving separation of concerns. For this purpose the software gets divided into into layers. The result can be schematically described as four layers.

3.1 Software layers

Entities

• innermost layer
• encapsulate Enterprise wide business rules
• can be an object with methods or a set of data structures and functions
• entities could be used by many different applications in the enterprise (unspecific)
• encapsulate most of the general and high-level rules
• least likely to change
• no operational change to the app should affect the entity layer

Use Cases

• contains application specific business rules
• the use cases orchestrate the flow of data to and from the entities
• direct the entities to achieve the goals of the use case

Interface Adapters

• set of adapters that convert data from use cases and entities to external agency (database or web)
• this layer can contain parts of the MVP architecture (Presenter belongs here)
• converts data from use cases into the form most convenient for the ui
• also includes all adapters that are necessary to convert data from external form

Frameworks & Drivers

• outermost layer
• contains framework specific code that communicates to the next inner layer
• in Android development contains ui (Activities, Fragments, Adapters etc.)
• framework specific implementation of storage and databases (ContentProvider, ORMs etc.)
• network implementation

3.2 Dependency Rule

• the layers / circles represent different areas of software
• outer circles are mechanisms
• inner layers are policies or strategies
• source code dependencies can only point inwards
• inner layer does not know anything about something in an outer layer
• program to interfaces not implementations

3.3 Data Transformation

• data formats used in outer layers should not be used by an inner layer
• normally data need to be transformed between the different layers (see example below)

NetworkMessage	CacheMessage	ViewMessage
message	message	message
id	id	id
from	from	from
--	cacheTime	--

3.4 Repository Pattern

The repository pattern (in the context of Android development) describes the data being transferred through a Repository implementation. It separates the business logic from the collection of the data. The repository implementation, which will be used in the Use Cases layer, picks different data sources depending on certain conditions. The data origin should be transparent for the client, which does not care if the data is coming from memory, disk or the web.

Example: When getting a user by id, the disk cache data source will be selected if the user already exists in cache, otherwise and HTTP request to an web api will be send to retrieve the data and later save it to the disk cache.

3.5 Main Advantages

• independent of frameworks, ui, databases: business rules are not bound to specific implementations
• testability: business rules can be tested without external elements