Clean Architecture (Uncle Bob)

Giriş

Clean Architecture kitabı 2012 yılında yazıldı

Mimari ve Yazılımda Kullanılan Kütüphaneler/Çatılar
Mimari ve yazılım iskeleti farklı şeylerdir. Açıklaması şöyle

“Your architectures should tell readers about the system, not about the frameworks you used in your system” — Robert C. Martin.

Spring vs Clean Architecture

Clean Architecture with Spring Boot: A good idea? yazısında bir karşılaştırma var. Clean architecture ile yazılımın Maintainability level iyileşiyor. Ancak Propagation cost artıyor

Screaming Rule

Açıklaması şöyle. Yani bir bakışta yazılımın ne yaptığı anlaşılabilmeli

The “Screaming” Rule

I couldn’t really find a name for the second diagram, so I called it “The Screaming Rule”, but I believe this is pretty accurate — let me explain!

Uncle Bob stated on multiple occasions that the architecture of an application should scream at you what the application is all about. He even has a nice metaphor for it, saying that, when you see the blueprints of a building you can easily tell if the building is a church, a house, or a library. Similarly, the design of our software should shout banking, retail, or gaming, rather than Spring, .NET, or Flask. I highly encourage you to read his article where he goes as far as calling this design “The Screaming Architecture”.

The only way of achieving this expressive design is to put the use cases in front of the implementation details.

Bir cümle şöyle

The goal of software architecture is to minimize the human resources required to build and maintain the required system. 

Mimarinin Değişmesi

Bir cümle şöyle

When requirements change, the difficulty in making such a change should be proportional to the scope of the change, not to the shape of the change. The difference between scope and shape often drives the growth in software development costs. It is the reason that the first year of development is much cheaper than the second, and the second year is much less expensive than the third.

Mimari

Kitapta kullanılan şekil şöyle

Bu şeklin açıklaması şöyle. Günümüzde Use Case kelimesi yerine Service kelimesi kullanılıyor.

The Dependency Rule

The first diagram is a visual representation of the “Dependency Rule”. This rule states that all the source code dependencies should point inwards. As a result, the Controllers will depend on our Domain Services, and they will depend on our Entities — which will sit at the center of our application.

In other words, our Entity objects do not know anything about the use cases, which, in turn, do not know about the framework. As a result, we will decouple the business rules and use cases from the framework and delivery mechanisms. ...

This idea was largely accepted and adopted: we can see everywhere this Controller — Service — Repository layer separation. There is a small difference though: maybe you have noticed that the “Use Case” classes from the original diagram are replaced here by “Services”.

Clean Architecture Kitabındaki Mimariye Benzeyen Türevler

Açıklaması şöyle. Hexagonal Architecture yazısına bakabilirsiniz. Bence Hexagonal Architecture daha önce ortaya çıkmış bir kavram. Dolayısıyla Clean Architecture ilham almış diyebiliriz.

Since then, his diagram has been used many times by various tech writers and conference speakers. Some of the original ideas were slightly changed or enhanced, leading to different names for the resulting designs: For instance, you might find it labeled as “Hexagonal Architecture” or “Ports and Adapters”.

Eleştiriler

Microservice mimaride bu Clean Architecture yapısını eleştiren bir yazı burada. Güçlü ve zayıf yönleri şeklen şöyle. Yani reliability ve security kısımları zayıf

Mimarinin Özellikleri

Bazı maddeler şöyle.

Some characteristics of a clean architecture, as described on the blog post, are:

1. Independent of Frameworks. 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 any external agency. In fact your business rules simply don’t know anything at all about the outside world.

Aslında bu maddelerin bence en önemlisi şunlar. Yani yazılımın test edilebilir olması ve teknolojinin kolayca değiştirilebilmesi.

A Clean Architecture style has a positive effect on maintainability:

- We can test domain entities and use cases without a framework, UI, and infrastructure.

- Technology decisions can change without affecting domain code. And vice versa. It is even possible to switch to a new framework with limited effort.