The Clean Architecture

• Original link: the Clean Architecture
• Translator: Zimoguo

• Reviewer: 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 is made up of Alistair Cockburn is presented by Steve Freeman and Nat Pryce in their book growing Object oriented software.
• onion Architecture (onion Schema)   proposed by Jeffrey Palermo. The
• Scream Architecture (screaming Architecture)   is Uncle Bob (the author of this article).
• DCI architecture   proposed by James Coplien and Trygve Reenskaug. The
• BCE schema   is Ivar Jacobson. In his book "Object Oriented software engineering:a use-case driven approach" there is a large reference to this architecture.

Although these articles differ in detail, they are generally very similar. They focus on separation by dividing the software into layers to achieve the separation effect. Each layer contains at least one business plan or interface.

These architectures have the following characteristics:

1. Independent framework
   These schemas do not depend on the loading of certain libraries, allowing you to use the framework as a tool without restricting your system;
2. Can be tested
   Business planning is tested without a UI interface, database, Web server, or other external elements;
3. Independent of UI
   The UI is easy to change without changing the rest of the system, and the Web interface can be replaced by the console interface without changing the business plan; 4. Database Independent
   You can switch to Oracle,sql server,mongo,bigtable,couchdb or other types of databases, business rules are not tied to the database; 5. Independent of any external agents
   In fact, your business plan doesn't need to know the outside world.

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

Dependency rules

Concentric circles represent different areas of the software, in general, the closer to the center of the software level will become more and more high, outer circle is the mechanism, inner circle is the strategy.

The override rule allows the schema to follow a dependency rule, which indicates that the source code can only be relied upon, the inner ring does not know about the outer ring together, in principle, the name of the outer ring Ring declaration does not need to be mentioned in the inner ring, including the name of the function, class, variable, or other software entity

For the same reason, the data format used in the outer circle should not be used in the inner circle, especially when the format is generated by an outer circle frame, and we do not want the outer circle to affect the contents of the inner circle

Entity

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

If you don't have a project and simply write an application, these entities are the business objects of the application. They encapsulate the most common, superlative rules. When outside changes, they are most likely to change, for example, you don't want these objects to be navigated by a changed page or security impact, Changing the operation of a particular application should not affect the entity layer.

Case

The business rules applied at this tier contain application-specific business rules that encapsulate and implement all of the system use cases, which orchestrate the flow of data into and out of the entity, instructing those entities to use the business rules within their project scope to reach the target of force.

We do not want to change the layer when the entity is affected, nor do we want the layer to be affected by external changes, such as database, user interface, or any common frame changes, this layer is separated from this part.

We do this, but we want to change the use cases of the software layer when the operation of the application is changed, and the code of this layer will be affected when the use case details change.

Interface Adapter

This layer of software is a conversion of digital adapters, from the most convenient format of use cases and entities to the most convenient format of some external institutions, such as databases or Web pages, this layer completely contains the GUI MVC architecture, Proxy, view, controller belong to this layer, the model is only from the controller back to use cases, The data structure is then from use cases to proxies and views.

Similarly, in this layer data is converted, from the most convenient form of entities and use cases to form the most convenient use of the persistent framework, namely the database. Any code in the inner circle should not know anything about the database. If this database is a SQL database, all SQL should be limited to this layer, Especially in this layer of operations on the database.

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

Frameworks and drivers

The outermost layer is typically made up of frameworks and tools, such as databases, web frameworks, and so on. In general, you don't write too much code on this layer, but instead put code in the inner circle.

This layer has a lot of detail, the Web page is a detail, the database is a detail, we keep the outer layers of these details received less damage.

Only four rings?

No, the circle just conveys meaning, you may find that you use not only these four, there is no rule you have to use these four rings, then, the dependency rules always apply, the source code is always inward dependent. The higher the level of abstraction inside the circle, The outermost circle is the specific detail of the lower level. The inside of the circle, the inner layer of abstraction and encapsulation is higher, the innermost circle is the highest and the most common.

Crossing boundaries

The bottom right of the graph is an example of how we cross the boundary, which shows that the controller and the agent communicate with the next layer of use cases. Note the control flow, which begins with the controller, moves through the use case and ends with the agent's execution. Also note the source code dependencies, which point to the inside use case.

We usually use the dependency inversion principle to explain this apparent contradiction, like the Java language, for example, we will orchestrate interfaces and inherited relationships so that source code relies on opposing control flows across the right side of the boundary.

For example, consider the proxy that the use case needs to call. However, you do not need to call directly because this violates the affinity rule: names in the outer ring do not need to be mentioned in the inner ring. So we call the interface in the inner ring (the use case output port shown here), and the outer ring implements it.

The same technology is applied across the boundary of the system structure, regardless of the direction of the control flow, we create the source code dependence with the advantage of dynamic polymorphism, against the control flow, so that we can conform to the dependency rules.

What is data spanning boundaries

Data that usually crosses the boundary is a simple data structure that can be transmitted using basic structures or simple data. Or the data can be simply called in a function, or you can package it into a hashmap, or construct it into an object, it is important to detach, to operate simply, Crossing boundaries through data structures. We don't want to cheat through entities and data, and we don't want any kind of dependency violation rules in the data structure.

For example, many database framework response queries return a convenient data format, which we call the row structure. We don't want to cross 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 transfer data across borders, it always uses the format of the most convenient inner ring.

Conclusion

Conforming to these simple rules is not difficult, and will save you a lot of headaches in the process of moving forward, through software layering, compliance with dependency rules, creating a system that is inherently detectable, means having its own benefits. When an external part of any system is obsolete, such as a database or web framework, You can replace those obsolete elements with the least amount of worry.

The Clean Architecture