Skip to main content

Clean Architecture

Intro​

These architectures all have the same objective, which is the separation of concerns. They all achieve this separation by dividing the software into layers (Business rule layer, interfaces layer etc).

Each of these architectures produce systems that are:​

1. Independent of Frameworkds​

The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.

2. Testable​

The business rules can be tested without the UI, Database, Web Server, or any other external element.

3. Independent of UI​

The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.

4. Independent of Database​

You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.

5. Independent of external agentcy​

In fact your business rules simply don’t know anything at all about the outside world.

The Dependency Rule​

The concentric circles represent different areas of software. In general, the further in you go, the higher level the software becomes. The outer circles are mechanisms. The inner circles are policies.

The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards.

Entities​

Entities encapsulate Enterprise wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions.

User Cases​

The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.

Interface Adapters​

The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web.

It is this layer, for example, that will wholly contain the MVC architecture of a GUI. The Presenters, Views, and Controllers all belong in here. The models are likely just data structures that are passed from the controllers to the use cases, and then back from the use cases to the presenters and views.

Frameworks and Drivers​

The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards.

This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.

Only Four Circles?​

不一定是只有四层，根据需要决定。只需要遵从 The Dependency Rule 原则，依赖的顺序是从外部到内部，越往内部代码抽象层次越高。

Crossing boundaries​

当内层需要调用外层代码时，这会违反 The Dependency Rule 原则，因此我们需要用到 Dependency inversion principle 方法，将外层组件抽象出一个 interface 并在内层使用。

What data crosses the boundaries​

首先，数据方便传输易于使用即可。

其次，数据的格式应该按照方便内层使用的格式为主，而不应该将数据库的整行数据格式直接传递给内层，因为这违反了 The Dependency Rule，内层不应该知道外层的数据结构。

Resources​