The Clean Architecture, cleanarchitecture

The Clean Architecture, cleanarchitecture

• Original article: The Clean Architecture
• Translator: zimoguo

• Proofreader: Mr. Simple

In the past few years, we have seen some ideas about the system framework:

• Hexagonal Architecture (Hexagonal Architecture) (a.k. a. ports and Adapters) This architecture was proposed by Alistair Cockburn and proposed by Steve Freeman and Nat Pryce in their book Growing Object Oriented Software.
• The Onion Architecture author is Jeffrey Palermo.
• Screaming Architecture is initiated by Uncle Bob (author of this article ).
• The DCI architecture is initiated by James Coplien and Trygve Reenskaug.
• The author of the BCE architecture is Ivar Jacob. In his book Object Oriented Software Engineering: A Use-Case Driven Approach, he mentioned A lot about this architecture.

Although these articles vary in details, they are very similar in general. They separate concerns and divide the software into layers to achieve the separation effect. Each layer contains at least one business plan or interface.

These architectures have the following features:

1. Independent framework
   These architectures do not depend on the loading of certain databases. They allow you to use the framework as a tool without limiting your system;
2. Testable
   Business planning should be tested without the UI, database, web server, or other external elements;
3. Independent from the UI
   The UI is easy to change, without changing other parts of the system. The webpage interface can be replaced by the console interface without changing the business planning. 4. It is independent of the database.
   You can switch to Oracle, SQL Server, Mongo, BigTable, CouchDB, or other types of databases. Business Rules are not bound to databases. 5. They are independent of any external proxy.
   In fact, you do not need to know the outside world in your business planning.

The chart at the top of this article integrates the concepts of these architectures.

Dependency rules

Concentric circles represent different areas of the Software. Generally, the closer the software is to the central position, the higher the software level. The outer circle is the mechanism, and the inner circle is the strategy.

The coverage rule allows the architecture to follow the dependency rule. This rule indicates that the source code can only be depended inwards. The inner ring does not know about the outer ring. In principle, the name of the outer ring declaration does not need to be mentioned in the inner ring, including the names of functions, classes, variables, or other software entities.

For the same reason, the data format used in the outer circle should not be used in the incircle, especially when the format is produced by the frame of the outer circle. We do not want the outer circle to affect the content of the incircle.

Entity

An entity encapsulates business rules within a project. An entity can be an object method or a set of data structures and functions, as long as the entity is used by different applications in the project.

If you do not have a project but simply write an application, these entities are the Business Objects of the application. they encapsulate the most common and most advanced rules. when external changes occur, they are most likely to change. For example, you do not want these objects to be affected by a modified page navigation or security. Operations that change a specific application should not affect the entity layer.

Use Cases

At this layer, application business rules include application-specific business rules, which encapsulate and implement all system use cases. These use cases orchestrate the inbound and outbound entities of data, indicates that these entities use business rules within their projects to reach the goal of hard work.

We do not want to change the layer to affect the entity, or the layer to be affected by external changes, such as changes to the database, user interface, or any common framework, this layer is isolated from this part.

We do this, but we want to change the operation of the application to affect the use case at the software layer. When the detailed information of the use case changes, the code at this layer will also be affected.

Interface adapter

This layer of software is an adapter for converting numbers, from the most convenient use cases and entities to some external organizations with the most convenient format, such as databases or web pages, this layer completely includes the MVC Architecture of the GUI. proxies, views, and controllers all belong to this layer. However, this model is transmitted from the Controller Back to the use case, and then from the use case to the data structure of the proxy and view.

Similarly, data at this layer is converted from the most convenient entities and use cases in the form of the most convenient use of the persistent framework, that is, the database. no code in the incircle should know anything about the database. if the database is a SQL database, all SQL statements should be restricted at this layer, especially when operating on the database.

In addition, other adapters at this layer need to convert data from external situations (such as external services) into internal forms of use cases and entities.

Framework and driver

The outermost layer is generally composed of frameworks and tools, such as databases and web frameworks. Generally, you do not write too much code on this layer, but paste the code into the inner circle.

There are a lot of details on this layer. The web page is a detail, and the database is a detail. We keep the outer layers of these details less damaged.

Only four rings?

No, the circle only conveys the meaning. You may find that you are not only using these four rings, but not specifying that you must use these four rings. Then, the dependency rules are always applicable, the source code is always dependent on the source code. the higher the abstraction level to the inside of the circle, the lower the detail of the outermost circle. the higher the abstraction and encapsulation layers to the inside of the circle, the highest and most common layers of inner circles.

Crossing boundaries

The lower-right corner of the figure shows an example of how we can traverse the border. It shows how controllers and proxies communicate with the next use case. note that the control flow begins with the Controller and ends with the execution of the agent by moving through the use case. pay attention to the source code dependency and point to the inner use case.

We usually use the Dependency inversion principle to explain this obvious contradiction, such as the java language. For example, we will orchestrate the relationship between interfaces and inheritance so that the source code is dependent on the control flow on the right side of the crossing border.

For example, consider the proxy to be called in the use case. however, you do not need to call it directly because it violates the correlation rule: the name in the outer ring does not need to be mentioned in the incircle. therefore, we call the interface (the use case output port shown here) in the inner ring to implement it in the outer ring.

The same technology is applied in the system structure that spans boundaries. No matter where the control flow is, we create source code dependencies with the advantage of dynamic polymorphism and oppose the control flow, so that we can comply with the dependency rules.

What is data crossing boundaries?

Generally, data that spans boundaries is a simple data structure that can be transmitted using basic structures or simple data. or data can be called simply in a function, or you can package it into a hashMap or construct it into an object. What is important is separation, simple operation, and cross the border through the data structure. we do not want to cheat through entities or data, and do not want any dependency in the data structure to violate dependency rules.

For example, many database frameworks return a convenient data format in response to queries, which is called a row structure. we do not want to span the line structure inward, which violates the dependency rules because it forces the inner ring to understand something about the outer ring.

Therefore, when we transmit data across boundaries, it always uses the most convenient Inner Ring format.

Conclusion

It is not difficult to comply with these simple rules, and it saves you a lot of headaches during the process of advancement. By using software layering and complying with dependency rules, creating a system is essentially measurable, it means it has its own benefits. when any external part of a system is used, such as a database or web framework, you can replace outdated elements with minimal worries.