These notes are from Clean Architecture book by Robert C.Martin (Uncle Bob) for my self-reference and will be updated as I progress through the chapters.
Part 1 - Introduction
- Both Architecture and Design points to same things in software development (Low-level and high-level details).
- The goal of Architecture is to minimize the amount of human resource required to build and maintin the required system in the long run.
- Tale of 2 Values
- Behaviour: A software program must satisfy the functional requirements.
- Architecture: A software system must be in a good shape. Easy to extend for new requirements without starting from scratch.
- Both must be satisfied, but if Architecture is compromised, it will become too hard to add new features and proceed further.
- Business managers always go with Behaviour beacuse of the estimate they have projected.
- Developers must fight for a good design and architecture.
- To effectively segregate tasks author recommends to use Eisenhower Matrix
- urgent & important (top priority)
- urgent & not important (delegate)
- not urgent but important (schedule)
- not urgent and not important (avoid)
Part 2 - Programming Paradigms
Programming Paradigms are considered the building blocks (or) bricks of code.
- Different paradigm exists.
- structured
- object oriented
- functional
- Each paradigm enforces a particular discipline on the code. Djisktra's paper "Goto considered harmful"
- Structured programming imposes discipline on direct transfer of control.
- Object oriented programming imposes discipline on indirect transfer of control.
- Functional programming imposes discpline upon asignment.
- These paradigms restrict the way we code in one way or the other enforcing a particular discipline.
- What does these paradigms have go to do with Architecture or design? Examples
- Polymorphism as the mechanism to cross architectural boundaries.
- functional programming to impose discipline on the location of and access of data.
- structured programming as the algorithmic foundation of our modules.
- In short, function, separation of components and data management.
- Decompose functional requirements into atomic verifiable units (functions) and verify their behaviour with unit tests
- Polymorphism paves way for a plugin architecture and depedency inversion for source code dependency over flow of control.
- Author celebrates the power the dependency inversion that polymorphism of OO approach provides.
- A scalable application requires concurrency. The immutable property of functional paradigm (pure functions) helps us achieve great concurrency.
- A well structured application would be segregated into components that mutate variables and components that don't.
- We could take event sourcing model where we don't store and update the state for every transaction, instead we could log the transactions and derive state from it at any given time. But that assumes infinite storage and infinite processing power.
- To summarize, each paradigm restrict some aspect of the way we write code. For the last half-century we have learned what not to do.
Part 3 - Design Principles
- Good software systems begin with clean code.
- On one hand, if the bricks aren't well made, the architecture of the system doesn't matter.
- On the other hand, you can make a mess with a well made bricks. This is where design princples comes in.
- The design principles tell us how to arrange our functions, modules and data structures and how they should be interconnected.
- SOLID is one such design principle.
- The goal of this principles is to create mid-level structures that
- tolerate change,
- are easy to understand and
- are the basis of components that can be used in many software systems.
- SOLID
- SRP (Single Responsibility Principle)
- a module should be responsible to one, and only, one actor.
- OCP (Open-Closed Principle)
- LSP (Liskov Substitution Principle)
- ISP (Interface Segregation Principle)
- DIP (Dependency Inversion Principle)