The Beginning

Spanish

This representation basically has the same meaning as Uncle Bob's original post on Clean Architecture. So, there is not much to add, except that the elements have been arranged in a convenient way to be able to give rise to other diagrams.

This can be summarized as follows:

🔳 Layers or Levels

Rectangular shapes visually represent the layers or levels in any architecture in a very simplified way, where the level of abstraction increases as you go along. Therefore, the outer layers have a low level of abstraction, while the inner layers have a high level of abstraction.

➡️ Dependency Rule

• The outermost layers represent the details and the inner layers represent the policies.
• Arrows represent code dependencies that should point only inward.
• The internal layers must not have knowledge of the elements of external layers, including the data formats used.

Now, to talk about each layer, we will use this class diagram to represent it:

Enterprise Business Rules

It contains the general, critical or application-independent business rules that would exist even if there were no system to automate them. These rules are represented by "Entities", which contain a small set of important business rules that operate on critical data, and focus exclusively on the business aspect.

Example
The Loan class is a business entity that defines attributes such as the amount borrowed, the interest rate and the term in months. These attributes are used for the calculateInterest() method, therefore the entity exposes behavior. It can be named Business Object (BO) or Business Entity (BE), so the class can be called LoanBO or LoanBE.

Application Business Rules

Contains the application-specific business rules that describe how an automated system is used. These rules are represented by "Use Cases" or also known as "Interactors" and specify how users interact with business objects and the system, without focusing on the appearance of the system or specific details.

It is proposed that, to access the functionality of the use cases, it is done through a service interface. This interface brings together the functionality of all the use cases and represents a more convenient way rather than calling each use case directly.

Example
A use case specifies the required inputs, the output to be returned to the consumer and the processing steps required to produce that output; this will then possibly be converted into a class called LoginUseCase or LoginInteractor. A use case does not always use business objects, only when policies require it.

Aspects on how to request and respond

• It is irrelevant how the data enters and leaves the system.
• Use simple data structures for their inputs and return simple data structures as outputs
• The data structures used must not depend on anything that violates the dependency rule, such as dependencies to Business Objects.

Similarities with the domain

The business rules of the application and the business rules of the company integrate what is known as "Domain" in the sense that they represent the business logic, as explained by Martin Fowler and Eric Evans:

The remaining piece is the domain logic, also referred to as business logic.

- Martin Fowler, Patterns of Enterprise Application Architecture, 2002

The design and implementation of business logic constitute the domain layer

- Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, 2003

Interface Adapters

Here reside the MVC, MVP and MVVM patterns, as well as adapters to transform data to the most convenient format.

Example
Here we can observe the MVP pattern. In addition, we delegate the responsibility of converting from one format to another to the Mapper class.

Technical Infrastructure

It represents the detail and consists of frameworks, libraries and tools.

Example
For example, if we are on Android, a CustomView can be an Activity, a Fragment or any other type of custom view, while CustomRepository can have dependencies towards RoomDatabase.