General characteristics of the architecture
Uncle Bobarticle summarizes the architecture should have the characteristics:
框架独立: The architecture does not depend on some software libraries that are fully loaded with functions. This allows you to use such a framework like a tool, rather than cram the system into their limited constraints.
可测试性: Business rules can be tested without UI, database, Web server, or other external elements.
UI独立: Complete UI simple modification without changing the rest of the system. For example, the Web UI can be replaced with a console UI without changing business rules.
数据库独立: The business rules are not bound to the database, so you can replace Oracle or SQL Server, for Mongo, BigTable, CouchDB, or other databases.
外部机制独立: In fact, business rules don’t know anything about the outer layer at all.
Based on the above characteristics
Clean The core idea is object-oriented programming, decoupling projects through the principle of layering and dependency inversion.
Clean architecture layering
Clean The architecture can roughly divide a project into four layers, as shown in the onion diagram above:
Interface Adapters: Interface adapter
Frameworks and Drivers: Framework and drivers
Entity is in
企业范围more common among different applications within the core object. It doesn't really matter what the specific form of the entity is. It can be an object containing methods or a series of data structures and functions. But it must contain the most common and highest-level rules. Any changes outside the entity layer cannot affect the entity.
Examples include use
应用范围specific business rules within. The use case layer integrates and implements all the use cases required in the application. These use cases coordinate the flow of data to and from the entities and direct the entities to use their enterprise-wide business rules to achieve the goals of the use case.
Similarly, the code at the use case layer should not be affected by changes in its outer layer. For example, the replacement of database frameworks, UI frameworks or other general frameworks should not affect the use case layer code.
Only when the business logic of the application changes, can the relevant code of the use case layer be adjusted.
This layer uses a series of adapters to convert data formats that are easy to use at the use case layer and entity layer into data formats that are easy to use by frameworks such as the outermost database and Web.
This layer is equivalent to the dividing line between the inner layer and the outer layer. This layer is the specific business logic and the data structure operated by the inner layer, and outside this layer are the libraries, frameworks, etc. used by the project and the data operated by the outer layer. In this way, the business logic is separated from the use of UI and technology, and the inner and outer layers are connected to each other through the function of the adapter.
The existence of the interface adapter allows the project to be developed at the same time as the inner and outer layers.
Frameworks and Drivers
This layer is the outermost layer of the project, and generally includes the frameworks and tools used in the project, such as databases and Web frameworks. All the frameworks and tools used in the outermost layer should be replaced at any time with minimal cost.
In accordance with the
Cleanframework for thinking should not hold the inner layer is the outer layer of the object. The outer layer can access the inner layer directly through the inner layer object, so how does the inner layer access the outer layer? This can be
依赖倒置原则solved by. The simple understanding of dependency inversion is to rely on abstraction instead of concrete. A certain logic in the outer layer can be abstracted into an interface, and the inner layer can call the concrete implementation of the outer layer interface through the interface to achieve the purpose of accessing the outer layer.
Application of Clean Architecture in Android Project
Cleanlater architecture, we look at how the
Cleanidea of architecture applied to
Androidthe project. I mainly through the following two projects to learn
Cleanhow to structure ideas are applied to
While the above two projects are
MVP - Cleanthe development of a combination of two ways of architecture. But its focus is different:
Android-CleanArchitecture: This project is a
Cleanframework for thinking in
Androidthe full expression project. It is ideal for
Androiddevelopers to learn
architecture-samples: This project shows how to use different architecture development
todo-mvp-cleanmore branches using
Cleanarchitecture layer with embodiments of Thought to
Psimplify complex business logic layer.
Data in this chapter is to learn
Cleanthinking that we mainly to introduce
Android-CleanArchitecturethe project. But the study also strongly recommends that
Android project layering
Android-CleanArchitectureThe project of
Cleanthinking plotted onion is as follows:
See this picture you may have doubts
Presenterslayers understanding, that
Mlayer where to go. In fact, this project
Presenterslayer operations data model.
Correspondence between project modules and levels
The author divides the project into three modules, as shown below:
The functions of the three modules and which layer corresponds to the onion diagram are as follows:
Presentation Layer, Corresponding to this module
Presentersthe two layers. Responsible for processing all logic related to the view. Have also introduced a
Presentersthe data structure of two processing, so in fact,
MVPare present in this module. But the function is different from the past. It
Vstill represents a view, and
Pno longer processes business logic, but uses an adapter to connect the presentation layer and the use case layer for data exchange. It
Mis a pure data structure that corresponds to the project
Domain LayerThis module corresponds to
Use Caseslayer. Responsible for the realization of all business logic use cases in the project. And defines
UserRepositoryinterfaces for use cases call.
Data Layer, Corresponding to this module
UIthe two layers. There may be a bit difficult to understand, and
Entitieslayer well understood, there are
UIlayers anything. Please note the distinction between
Androidmodules dependence and projects
Cleanof different levels of dependence between the architectures. Let's look at
Cleanthe architecture of thought, the outermost layer in addition to
UIwhat is not there a database, tool libraries. Use this module
Repositorymode processing entity data, including a data line, local data processing, wherein the data line might be used
Okhttpother specific implementation, the local data may be used
Roomand the like, which should not be in the
Cleanarchitecture The outermost layer.
This can also understand why the author would
UserRepositoryinterface is defined in
Domain Layerthe a.
After introducing the division of project modules and the reasons for such division, let's finally look at how data is transmitted in the project. As shown below:
You can see that the data in the project is passed through the observer mode.
Combined with the project itself, you can see that the author has defined a data structure (
UserEntity、User、UserModel) for each module and has a corresponding converter
Mapper. The advantage of this is that the various modules can be decoupled to the greatest extent. But for some very simple business projects, it is not necessary to define a data model for each module, and it is too cumbersome. In fact, for some small projects, it is already normal for only one data structure to exist in a certain business in the project.
Personally understand that if the view development and business development are separated, only two data structures are needed
XxxEntitythat is, decoupling and reducing some cumbersomeness. In the discussion of Clean architecture , the author gave different opinions. Still that sentence
Pay attention if it feels useful