This book is an easy read with lots of simple examples and clarity of thought which will improve any architects thinking when designing a system.
I will summarize the quick takeaways from the book for software architecture a) Architecture minimizes resources to build and maintain a system and improves productivity
b) Software is "soft" due to changeability (ties in with points made in Evolutionary Architecture book)
c) Architecture is either "urgent and important" or "not urgent and important"
d) Three major paradigms only : Structured, OO, Functional
e) Software is more physics and science than formal mathematics
f) OO is about encapsulation, inheritance and polymorphism
g) Functional is more about immutablity
h) SOLID principles are important
i) Components are the default in architecture (DLL, Jars, Ears)
j) Component Cohesion : Reuse/Release, Common Closure, Common Reuse principles. There is a tension among these principles.
k) Component Coupling : Avoid cyclic dependencies. Separate stable from volatile components. Depend in direction of stability
l) Fanout/(Fanin + Fanout) metrics are significant.Abstraction measured by Num_Abstract/Num_Total components
m) Architecture leaves options open
o) Architecture allows single click deployment
p) Architecture communicates operational needs
q) Architecture minimizes maintenance
r) Software can be decomposed into policy and details. Policy is the value of software
s) Decoupling modes : Source Level, Deployment Level, Services Level (e.g. Microservices). Use the mode based on context
t) IO is irrelevant to architecture u) Level : The distance of policy to I/O
v) Business rules are a reason why software exists and must be unsullied
w) The architecture should "scream" about the purpose of a system rather than the frameworks
x) Types of architecture : Hexagonal, DCI, BCE.
y) Clean Architecture : Entities <- Use Cases <- Controllers <- Implementation frameworks. Entities are core for example and use cases are next level and know about entities and so on
z) Humble objects separate hard to test functionality from other functionality and used at boundaries.Main the dirtiest component as it initializes other components and passes the data to higher level components
a.1) Just having services does not make an architecture. Components should be related to services
a.2) Tests should be designed as part of a system become unmaintainable
a.3) User hardware abstraction layer and OS abstraction layer in code to make "firmware" more like "software"
a.4) Database, Web , Frameworks are details only and not core. Don't couple to them too much