Clean Architecture

As I already stated Clean Architecture was the main reason I started this journey. If you are seriously interested in reading more about Clean Architecture I kindly recommend Uncle Bob’s book. The book features several parts. One introduce the SOLID principals on architecture level while others focus more on the Clean Architecture itself. The “problem” with the book is that does not have easy adoptable guidelines. There is some sample code but not in the form for general re-usage. So it leaves some room for interpretation – which I did.

On this blogpost Uncle Bob summarized the core ideas behind the Clean Architecture (CA). Before continue here please read it first.

Copyright by Rober C. Martin

If you look at the above diagram from Uncle Bob you’ll see two things.

The “rings” or “layers”. An inner ring does not know anything about outer rings and outer rings only know the next inner ring. In the center there are the business entities. Uncle Bob leaves it open if you do Domain Aggregates or some other kind of business-objects. Then there are the use-cases from the business. This is where the “dance of the entities” is orchestrated. In other architecture this is known as the application-layer.

When you look at the bottom right there is a second diagram: The flow of control. At first I didn’t get this one while later I spent serious time thinking on how to implement something comes close to this flow in a MVC web application. More on this later.

The nice thing about CA (and others like The Onion Architecture) is that it nicely separates concerns and therefore dependencies. This leads to way easy writing of automated unit-tests which is a big deal from my point of view.

I somewhere read that CA can nicely be combined with Domain Driven Design – it can act like a host to DDD so let’s quickly address DDD.

Domain Driven Design (DDD)

If you like to get quick intro to the core of DDD I can recommend the book DDD Quickly by InfoQ freely available online. Another good but a little thicker book is Domain Driven Design Distilled by Vaughn Vernon.

How I see the big value of DDD:

The DDD principals puts the business-perspective back on the code. The same does CA. The goal is that we can see the main business values our app addresses in quickly in our code without the need of digging to tons of techie stuff first. It should be obvious for a reader what main business-needs the software addresses. Its why the software has the right to exist. Uncle Bob calls this “[Screaming Architecture]”(https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html).

One of the nice things with DDD is that one build the core of the code around the business needs in a nice object-oriented manner.

With these basics in place let’s jump into my implementation …