Clearn Architecture


Author :: Kevin Vecmanis


A review of key concepts I learned in the book Clean Architecture: A Craftman’s Guide to Software Structure and Design

Table of Contents


Introduction

  • The obvious appeal of architecture is structure, and structure is something that dominates the paradigms and discussions of sofware development.
  • Despite this, the gross structure of so many sofware syste,s odten defies either belief or understanding.
  • Physical buildings and structure have little choice but to respect the laws of physics. Software, on the other hand, isn’t subject to these same rules. Distastrous physical architecture is obvious - building fall over or collapse. Disastrous software architecture is often much harder to diagnose once it’s been built and layered upon.
  • This is because software is recursive and fractal in nature. Everything is details.
  • The author makes the argument that more design activity and focus in software than in building architecture.

Notable Quotes

  • “Architecture represents the significant design decisions that shape a system, where significant is measure by the cost of change.”
  • “If you think good architecture is expensive, try bad architecture”
  • “Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other”
  • “The path we are interested in is the cleanest one. It recognizes the softness of software and aims to preserve it as a first-class property of the system”
  • “The only way to go fast is to go well”
  • “When software is dne right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized”.


Chapter 1: What is Design and Architecture?

  • The author asserts that there is no difference between design and architecture. None.
  • Architecture is often ysed in the context of something at a higher level that is divorced from the lower-level details, whereas “design” more often seems to imply structures and lower-level decisions.
  • The low-level details and high-level decisions are part of the same whole.
  • The author makes the argument that “the goal of software architecture is to minimize the human resources required to build and maintain the required system”.
  • By extension, the measure of design quality is simple the measure of the effort required to meet the needs of the customer. If that effort is low and stays low, the design is good. If the effort grows with each new release, the design is bad.

The Signature of a Mess

  • The signature of an architectural mess is exponentially increasing cost and effort with each new release.
  • Effort to maintain the system increases or stays the same, but the amount of new features being shipped is declining.
  • If the revenues of the business aren’t outpacing the increasing costs to maintain the code base, you have an economics problem on your hands.
  • Developers are in a perpetual “toroise and the hare” type of scenario.
  • The biggest code a team of developers can tell themselves is that writing messy code makes them go faster in the short term. In reality, making messes is always slower than staying clean.

Kevin Vecmanis