Overall thoughts on the book

Although the book “Clean Architecture” is written by famous voice in software engineering, Robert C. Martin, and indeed has a lot of great advice it certainly did not meet my expectations. In my opinion the book is very outdated, is very focused on old ways of building software, namely monolithic and 3-layer applications for commercial enterprises. Yes there are touches on embedded software as well as on SOA and micro-services, but they seem to have been added as an afterthought. At the very least I didn’t get the feeling author had any first-hand experience with resent trends.

There were few instances were I had to stop and think for myself that I completely disagree with the author. For instance, in “The Decoupling Fallacy” chapter the author argues that services are anyway coupled because they use same data passed around and modifying interface of data requires changes in many places. Well it depends on how you design your services and example given in book looked very artificial – not something that you would see in real world implementations. Luckily it is also the point that we can redesign services to reduce this kind of coupling.

For another instance, there was an advice on introducing dedicated testing API that can bypass security and other complications to streamline testing. This seemed very odd and potentially dangerous. It might help in some places, but I would imagine this is just making things worse in the long run. Anyway my opinion.

Don’t get me wrong the book is good as a food for thought and some chapters are really great, but I don’t think it will help you design clean architecture.

Chapter by chapter

The book starts with programming paradigms, such as structured programming, object-oriented, and functional. Not sure if this fits the overall topic of the book, but the overview of these paradigms is nice and gradually takes the reader to further topics.

After these there are chapters on SOLID design principles, which I think are great. This is probably the best part of the book. I even think SOLID could have been super-short standalone book. I really appreciate the way author consolidated these principles and described in details. In many ways people can attribute these principles to him, but don’t make this mistake – they existed before and different people described them in different ways, though it is still author’s public speaking and consolidation that made them stick in heads of so many software engineers. In fact I’ve probably given tech talk on them twice in my career. In case you don’t remember SOLID stands for 5 principles: Single responsibility, Open–closed, Liskov substitution, Interface segregation, Dependency inversion.

Later author introduces the concept of components, which he defines as smallest deployable pieces of software. We can apply the same SOLID principles from code level to component level. This is where the author introduces many new definitions, which I do not think got stuck in software engineer heads. At least they didn’t get stuck in my head and I don’t remember others ever talking about them. These are things like: reuse/release equivalence principle, common closure principle, common reuse principle, etc.

After this we go one level higher where we look at boundaries between components and how we build good architecture. This is where I started taking more detailed notes. Below are some raw notes almost “as-is” when I was taking them.

Boundaries: Drawing Lines

• Non-business decisions like architecture frameworks have to be deferrable.
• What lines to draw?
  • UI is independent from business rules.
  • Example with business rules and database where there is a boundary between the two and database depends on business rules.
  • We can make things that depend on core business rules to be plugins (GUI or Database can be considered “plugins”)
  • Great example is VS and Resharper
• Breaking system into components, marking some of them as core and making others to be inject-able plugins resembles dependency injection from code level on architecture level.

Boundary Anatomy

• Boundary crossing is when function from one component calls function from another.
• Boundary strategy: local process boundaries, services, linked components. Chattiness should always be limited.

Policy and Level

• Architecture is often about building directed acyclic graph.
• “level” is distance between inputs and outputs.

Business Rules

• Business rule are rules that make or save company money.
• Entity object embodying set of business rules.
• Use-cases are descriptions for automated system. They consists of: input, output, steps in between.
• Use-cases should not describe how application looks like.
• Business rules should be the most independent and reusable code in the system.

Screaming Architecture

• Architecture should scream what this software is for and not what frameworks or algorithmic approach it is implemented with.
• Frameworks are options that are to be left open.

The clean architecture

• Good architecture: independent of UI, database, frameworks and external agency; testable.
• Dependency Rule: source code dependencies must point only inward, toward higher-level policies.
• When we pass data across a boundary it is in a form more convenient for inner circle and such that it doesn’t create a dependency on outer circle.

Presenters and humble objects

• Humble Object pattern – separation of behavior by testable and hard-to-test. This introduces us to Presenter-ViewModel-View. At least this is how it looked to me.
• Database Gateways
• Data Mappers
• Service Listeners

Partial Boundaries

• Partial boundary is when you prepare to have two components but still keep them together.
• One-dimensional boundary is similar to a Strategy pattern.
• Service boundary interface is used by clients and implemented by service. This is classic for RPCs or other communication frameworks.
• Facade – even simpler boundary

Layers and boundaries

• Gives an exampe of Hunt the Wumpus game from 1972. I wasn’t even born then! While explaining it the book mentions among other things store for the game’s persistence layer can be in cloud? Hm… weird combo.

The Main Component

• Main component – something that controls everything else. Entry point into system.
• This chapter looked like it is there to fill-in the pages.

Services: Great and Small

• Arguing that SOA and microservices are only partially allowing for decoupling, and separation of development and deployment.
• In The Decoupling Fallacy the author argues that services are anyway coupled because they use same data passed around and modifying interface of data requires changes in two places.
• Fallacy of Independent Development and Deployment. Author says that development and deployment has to be coordinated and therefore this is a lie. I somewhat disagree.
• We can do SOLID on service level and this is where I do agree.

The Test Boundary

• “From architectural point of view, all tests are the same” – hm… “Their role is to support development, not operation” – hm…
• Design for testability
• Advices to have testing API that bypass security etc.

Clean Embedded Architecture

• Getting the app to work is “app-titude test”
• Target-hardware bottleneck – what you write only works on specific hardware and can only be tested there
• For embedded software engineers the job is to firm separation between firmware and software that sit on top of hardware. HAL – hardware abstraction layer (on top of firmware).
• A clean embedded architecture should hide hardware specifics and leave them only to firmware.
• Clean embedded architecture also separates software from operating system by introducing OSAL (operating system abstraction layer).

The Database is a detail

• Arguing that hard drives will have the fate of CDs and soon everything will be stored as in RAM, via data structures.
• Tells a story or marketing for RDBMS

The Web is a detail

• Talks about osculations of moving computing power between centralized place and distributing it
• Argues that GUI is a detail.

Frameworks are details

• When you decide on a framework you make one-directional marriege commitment

Case-study: video Sales

• Split by two dimentions: Single Responsibility Principle and Dependency Rule

Conclustion

It is an ok book but somehow I don’t think I can recommend it. It won’t be waste of time, of course, but you might feel like you didn’t get much out of it – the way I feel. The nuggets that do exist in the book, like chapters on SOLID is something you can read online or even watch numerous videos with Robert C. Martin online where he talks about them.