Clean Architecture - The Dependency Rule

Previously we made a beginning by exploring the concentric shells of Clean Architecture. Typically we describe application architecture in terms of horizontal layers. However, such a layered arrangement does not work for Clean Architecture. Or, it does work, but only if the layers are concentric and the overall structure leaves no doubt that business logic lives at the core.

Why concentric? Surely, the UI and the database live worlds apart, yet they are both represented in the outer Frameworks & Device shell.

Yes, UI and the database are located at opposite ends of the call chain—the UI receives a user event first while the database gets called last—however, conceptually, both are equally distant in dependency from the central business logic.

On the diagram, notice the arrows coming in from the left-hand side.

These represent The Dependency Rule: Outer layers depend on inner layers (as per the direction of the arrows). But—and this is a crucial part—inner layers do not depend on outer ones.

That is how Clean Architecture achieves pluggability—different parts in outer circles can plug into inner circles, and the inner circles don’t know nor care what outer layer source code will be called at runtime. As long as the outer layer behaves like a database, the inner circle should not care what kind of database is plugged in.

In fact, inner circles should not know about outer circles at all. Inner layers should avoid the mere mentioning of outer circles, say, in comments.

Why?

Because it would set up an implicit dependency on the outer, mentioned thing. For example, if a comment in business logic mentions the SQL Server database then we have set up an implicit dependency on SQL Server in a place where it does not belong.

What if we change database technology and replace our SQL Server database with a Mongo DB database? However, we forgot to update the comment accordingly, and now we have created a piece of misinformation in the business logic layer—the comment still mentions the database as SQL Server.

Ironically, other architectures frequently make it hard to replace one database technology with another. But with Clean Architecture, the pluggability property makes it about as easy as the process can be—which is the point.