Clean Architecture - notes

Notes from the book by R.C. Martin

Summary of thoughts

This is another bible from uncle bob. I like this one the best, because it has lots of architecture tips. I read this after clean code, so with out the clean code fundamentals you probably wont get this. But this is a great book.

2. A Tale of Two Values

Architecture

software was invented to be “soft”

3. Object-Oriented Programming

the UI and the database can be plugins to the business rules

7. The Single Responsibility Principle

a module should have one, and only one, reason to change

8. The Open-Closed Principle

a software artifact shuld be open for extension but closed for modification

20. Business Rules

describe the application-specific rules that govern the interaction between the users and the Entities

Request and Response Models

you might be tempted to have these data structures contain refrences to Entity objects. You might think this makes sense because the Entities and the request/response models share so much data. Avoid this temptation! The purpose of these two objects is very different. Over time they will change for very different reasons … violates the Common closure and Single Responsibility Principles.

21. Screaming Architecture

The Purpose of an Architecture

A good software architecture allows decisions about frameworks, databases, web servers, and other environmental issues and tools to be deferred and delayed.

Frmeworks are Tools, Not Ways of Life

the examples they write for how to use their frameworks are told from the point of a true believer … this is not the position you want

24. Partial Boundaries

YAGNI

28. The Test Boundary

Tests are not outside the system … they are parts of the system that must be well designed.

29. Clean Embedded Architecture

from the current product’s code … the tangled legacy code was the spec for the new product!

30. The Database is a Detail

Relational Databases

Many data access frameworks allow database rows and tables to be passed around the system as objects. Allowing this is an architectural error

Frameworks are Details

frameworks are not architectures

The Risks

frameworks … violate the dependency rule … inherit their code into your business objects

The Solution

don’t marry the framework

your business objects should not know about spring … use spring to inject dependencies into your Main

I Now Pronounce You …

There are some frameworks that you simply must marry

33. Case Study: Video Sales

Use Case Analysis

an abstract use case is one that sets a general policy that another use case will flesh out