Clean Architecture - Patterns, Practices, and Principles

Get Started. It's Free
or sign up with your email address
Rocket clouds
Clean Architecture - Patterns, Practices, and Principles by Mind Map: Clean Architecture - Patterns, Practices, and Principles

1. Presenter

1.1. Matthew Renze

1.2. @matthewrenze

1.3. [email protected]

1.4. Independent Software Consultant

1.5. Pluralsight Author

2. Software Architecture

2.1. High-level

2.2. Structure

2.3. Layers

2.4. Components

2.5. Relationships

3. Levels of Architectural Abstraction

3.1. Systems

3.2. Sub-Systems

3.3. Layers

3.4. Components

3.5. Classes

3.6. Data and Methods

3.7. (think in a pyramid)

4. Messy vs Clean

4.1. Messy

4.1.1. Looks like spaghetti code

4.1.2. hard to add and move things around without touching everything around it

4.1.3. Complex

4.1.4. Incosistent

4.1.5. Incoherent

4.1.6. Ridged

4.1.7. Brittle

4.1.8. Untestable

4.1.9. Unmaintainable

4.2. Clean

4.2.1. Lasagna

4.2.2. Distinct pieces that can be cut into more distinct pieces

4.2.3. Simple

4.2.4. Understandable

4.2.5. Flexible

4.2.6. Emergent

4.2.7. Testable

4.2.8. Maintainable

4.2.9. "an Architecture that is designed for the inhabitants of the architecture... not for the architect... or the machine "

5. Why Clean Architecture?

5.1. Cost/Benefit

5.2. Minimize Cost to Maintain

5.3. Maximize Business Value

5.4. "The first concern of the architect is the usability of the house, not that the house is made out of brick... " rephrased - Bob Martin

5.5. POINT

5.5.1. Architect/Architecture is supporting the NEEDS of the system first, not the implementation first.

5.5.1.1. focused first on essential, details can come later

5.5.2. Essential

5.5.2.1. Domain

5.5.2.2. Use Cases

5.5.3. Details

5.5.3.1. Presentation

5.5.3.2. Persistence

6. Domain Centric Architecture

6.1. Domain is key and important

6.2. Database is a detail on the outside

6.3. Pros

6.3.1. Focus on essential

6.3.2. Less coupling to details

6.3.3. Necessary for Domain Driven Design (DDD)

6.4. Cons

6.4.1. Change is difficult

6.4.2. Requires extra thought

6.4.3. Initial higher cost

6.5. pictures

6.5.1. pic

6.5.2. pic

6.5.3. 3

6.5.4. 4

7. Application Layer

7.1. What are Layers

7.1.1. Levels of abstraction

7.1.2. Single-Responsibility Principle

7.1.3. Developer roles / skills

7.1.4. Multiple implementations

7.1.5. Varying rates of change

7.2. Classic 3 Layer

7.2.1. --Users--

7.2.2. UI

7.2.3. Business Logic

7.2.4. Data Access

7.2.5. --Database--

7.3. Modern 4 layer

7.3.1. -- users --

7.3.2. presentation

7.3.3. application

7.3.4. domain

7.3.5. -

7.3.5.1. Persistence

7.3.5.1.1. Database

7.3.5.2. Infrastructure

7.3.5.2.1. O.S.

7.3.6. Pic

7.4. Details

7.4.1. Implements use cases

7.4.2. High level application logic

7.4.3. Knows about lower layers

7.4.4. No knowledge of upper layers

7.4.5. Contains interfaces for detaisl

7.5. Why

7.5.1. Pros

7.5.1.1. Focus is on use cases

7.5.1.2. Easy to understand

7.5.1.3. Follows DIP

7.5.2. Cons

7.5.2.1. Additonal Cost

7.5.2.2. Requires extra thoughts

7.5.2.3. IoC is counter-intuitive

8. Command-Query Separation - CQRS

8.1. Command

8.1.1. Does something

8.1.2. Modifies State

8.1.3. Should not return a value (ideally)

8.2. Query

8.2.1. Answers a question

8.2.2. Does not modify state

8.2.3. Always returns a value

8.3. Avoid mixing the two!

8.4. CQRS

8.4.1. Type 1

8.4.1.1. Single Database

8.4.2. Type 2

8.4.2.1. Read/Write Databases

8.4.2.2. 2 Databases

8.4.2.2.1. Read is optimized for... reads!

8.4.2.3. Can be eventually consistent

8.4.2.4. More complex, but LARGE performance benefits

8.4.3. Type 3

8.4.3.1. Event Sourcing

8.4.3.2. Don't store entities, store all the deltas

8.4.3.2.1. On read, run all the deltas and get the final value

8.4.3.3. Most complex

8.4.3.4. Benefits

8.4.3.4.1. Complete audit trail

8.4.3.4.2. Point-in-time reconstruction

8.4.3.4.3. Replay events

8.4.3.4.4. Rebuild production database

8.5. Why

8.5.1. Pros

8.5.1.1. More efficient design

8.5.1.2. Simpler within each stack

8.5.1.3. Optimized perofrmance

8.5.2. Cons

8.5.2.1. Inconsistent across stacks

8.5.2.2. Type 2 is more complex

8.5.2.3. Type 3 might be overkill

9. Functional Organization

9.1. "The architecture should scream the intent of the system!" - Uncle Bob

9.2. Building Analogy

9.2.1. Functional Organization

9.2.2. Component Organization

9.3. Silverware Examples

9.3.1. You put all "Eating Utensils" together

9.3.1.1. Forks, Spoons, Knives

9.3.2. You don't put all the forks together

9.3.2.1. Eating Fork, Pitch Fork, Tuning Fork...

9.4. Why

9.4.1. Pros

9.4.1.1. Spatial Locality

9.4.1.2. Easy to navigate

9.4.1.3. Avoid vendor lock-in

9.4.2. Cons

9.4.2.1. Lose framework conventions

9.4.2.2. Lose automatic scaffolding

9.4.2.3. Categorical is easier at first

10. Microservices

10.1. Domains

10.1.1. Often we try to use the same entity for multiple contexts

10.1.1.1. contexts could be

10.1.1.1.1. Sales associate

10.1.1.1.2. vs

10.1.1.1.3. Customer

10.1.1.2. Problems

10.1.1.2.1. validation is different on each side

10.1.1.2.2. properties we want to show are different

10.1.1.2.3. etc

10.2. Define

10.2.1. Subdivide system

10.2.2. Bounded contexts

10.2.3. Small teams

10.2.4. Independent

10.2.5. Similar to SOA

10.3. Why

10.3.1. Pros

10.3.1.1. Less cost for large domains

10.3.1.2. Smaller teams

10.3.1.3. Independence

10.3.2. Cons

10.3.2.1. Only for large domains

10.3.2.2. Higher up-front cost

10.3.2.3. Distributed system costs

11. Code Demo

12. Resources

12.1. Uncle Bob Clean Code Videos

12.2. Domain-Driven Design

12.2.1. Eric Evans

12.2.2. Book

12.3. Greg Young & Udi Dahan event sourcing articles

12.4. Presenter's website

12.4.1. matthewrenze.com