blog book reviews
A private blog of learnings and thoughts.

The Truth Behind The Clean Architecture Book

Oh boy, I was wrong about the Clean Architecture book… and I guarantee 99% of people who talk about this book have never read it before, but SOMEHOW have an opinion on it.

To review my raw notes (they are ugly) here they are exported from my kindle: Clean Architecture Raw Notes

Notice! Warning! Stop!

The reality is that "clean" is whatever the team is using at the time. Ideally, you are not caught in a cycle of learning and then implementing in a suboptimal manner. Ideally, you should learn by doing, not by idolizing. Often, clean architecture is the architecture that your team is already implementing.

My caveat for this post is that the current team I am working with at Microsoft uses clean architecture, which does not mean it's inherently better or worse—it's just what suits my team right now. So please, when you join a company, don't impose your style; it's likely to come across as emotional immaturity, regardless of your age or seniority.

Clean Architecture… WHY?

Business Value of Clean Architecture: The core idea behind adopting a clean architecture approach is to simplify development, ensuring that a system is easy to understand, debug, and modify. This architecture advocates for separating the concerns of a system into independent layers, prioritizing the business logic at the core. By doing so, it enables a structure where changes in one part of the system have minimal impact on others, Ultimately, clean architecture aims to create systems that are resilient to changes in external frameworks and new tech.

Clean Architecture is just one concept that if you get it right you will dominate.

Clean Architecture is mostly Dependency Inversion Principle at the micro level: In practice, clean architecture is the principle of Dependency Inversion. The principle suggests that high-level modules should not depend on low-level modules, but both should depend on abstractions. For example, consider this input/output scenario in pseudo-code

interface DataRepository {
    function fetchData()
}

class CloudRepository implements DataRepository {
    function fetchData() {
        // Fetch data from cloud
    }
}

class LocalRepository implements DataRepository {
    function fetchData() {
        // Fetch data from local storage
    }
}

class DataManager {
    DataRepository repository

    function DataManager(DataRepository repository) {
        this.repository = repository
    }

    function getData() {
        return repository.fetchData()
    }
}

Dependency Inversion allows for flexible data management strategies, decoupling the data source from the data consumption logic.

At a very high level what is clean architecture

Separation of Concerns: Clean architecture fundamentally advocates for the separation of concerns, ensuring that the UI, database, and business rules do not overrule each other. This separation means that business rules should not be bound to the UI or the database, nor should they rely on specific frameworks. Components communicate through well-defined interfaces, make it modular and easy to modify.

Thoughts

If implemented correctly, Clean Architecture can significantly enhance a team's velocity. While it might not be immediately apparent, I always am wary of claims that scream "velocity!". True velocity is achieved when each engineer has a clear understanding of the system's architecture, which is precisely what this book advocates for and in reality this book goes goes beyond mere coding practices to offer a holistic view on dealing with frameworks, dependencies, and even making architectural decisions.

It really

Even how to think about marriage… uh, yes…

Of course, the idea is that if everyone on the team follows 'Clean Architecture' principles, it could (IT COULD) become possible for anyone to jump into any project at any time…

But that's something I'll write about once I've earned some grey hair and reflect back on this post.