By the end of this lesson you can name the four rings of the Clean Architecture diagram and state the one rule that holds them together. You will also see why redrawing the picture does not make our code clean.

Almost every article about Clean Architecture opens with the same drawing of four concentric rings. Figure 0.2 is that drawing. Ignore the ring names for a moment, find the single arrow, and notice which way it points.

The rings give us vocabulary, and the vocabulary is genuinely useful. Reading Figure 0.2 from the outside in, each ring has one job:

• Frameworks and Drivers hold our machinery: the web host, Entity Framework Core, SQLite.
• Interface Adapters translate between that machinery and our application: controllers, request and response models, mappers.
• Use Cases describe what our application does when someone asks it for something.
• Entities hold the business rules that would be true even if our application did not exist.

We meet each of these rings again in Module 2, as a real .NET project we create ourselves, so there is nothing to memorize today.

The drawing tells us which categories of thing exist and roughly where they live. The drawing does not tell us how. How, in C#, does an inner ring save data to a database that sits on the outside? And it does not tell us when. Does this feature need a use-case class and an entity with behavior, or is it a lookup so small that wrapping it in ceremony makes our code worse?

Almost every Clean Architecture mess starts with someone who mastered the picture and never learned the how and the when. They created the four projects, drew the four rings on the team wiki, and then put all the logic in controllers anyway.

Cover the list above and name the four rings from the outside in. Then say which of them is allowed to mention Entity Framework Core by name.

In Figure 0.3 we faded the rings on purpose. The arrow is the whole lesson.

That arrow has a name. The Dependency Rule says that source-code dependencies may point only inward. Nothing in an inner ring may know anything about an outer ring.

Source-code dependencies point inward, always.

That single rule carries the whole of Clean Architecture, and the whole of our course. Everything else follows from taking the arrow seriously. We spend all of Module 2 on the arrow alone, because once the arrow is clear, the rings draw themselves.

You can now name the four rings and state the Dependency Rule in one sentence. New term in this lesson: the Dependency Rule. Clean Architecture did not arrive from nowhere, and it is not our only reasonable option. In the next lesson we lay out the whole landscape, so that we know what we are choosing against.