Clean Architecture - Patterns, Practices, and Principles

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

1. Domain Centric Architecture

1.1. Domain is key and important

1.2. Database is a detail on the outside

1.3. Pros

1.3.1. Focus on essential

1.3.2. Less coupling to details

1.3.3. Necessary for Domain Driven Design (DDD)

1.4. Cons

1.4.1. Change is difficult

1.4.2. Requires extra thought

1.4.3. Initial higher cost

1.5. pictures

1.5.1. pic

1.5.2. pic

1.5.3. 3

1.5.4. 4

2. Application Layer

2.1. What are Layers

2.1.1. Levels of abstraction

2.1.2. Single-Responsibility Principle

2.1.3. Developer roles / skills

2.1.4. Multiple implementations

2.1.5. Varying rates of change

2.2. Classic 3 Layer

2.2.1. --Users--

2.2.2. UI

2.2.3. Business Logic

2.2.4. Data Access

2.2.5. --Database--

2.3. Modern 4 layer

2.3.1. -- users --

2.3.2. presentation

2.3.3. application

2.3.4. domain

2.3.5. -

2.3.5.1. Persistence

2.3.5.1.1. Database

2.3.5.2. Infrastructure

2.3.5.2.1. O.S.

2.3.6. Pic

2.4. Details

2.4.1. Implements use cases

2.4.2. High level application logic

2.4.3. Knows about lower layers

2.4.4. No knowledge of upper layers

2.4.5. Contains interfaces for detaisl

2.5. Why

2.5.1. Pros

2.5.1.1. Focus is on use cases

2.5.1.2. Easy to understand

2.5.1.3. Follows DIP

2.5.2. Cons

2.5.2.1. Additonal Cost

2.5.2.2. Requires extra thoughts

2.5.2.3. IoC is counter-intuitive

3. Command-Query Separation - CQRS

3.1. Command

3.1.1. Does something

3.1.2. Modifies State

3.1.3. Should not return a value (ideally)

3.2. Query

3.2.1. Answers a question

3.2.2. Does not modify state

3.2.3. Always returns a value

3.3. Avoid mixing the two!

3.4. CQRS

3.4.1. Type 1

3.4.1.1. Single Database

3.4.2. Type 2

3.4.2.1. Read/Write Databases

3.4.2.2. 2 Databases

3.4.2.2.1. Read is optimized for... reads!

3.4.2.3. Can be eventually consistent

3.4.2.4. More complex, but LARGE performance benefits

3.4.3. Type 3

3.4.3.1. Event Sourcing

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

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

3.4.3.3. Most complex

3.4.3.4. Benefits

3.4.3.4.1. Complete audit trail

3.4.3.4.2. Point-in-time reconstruction

3.4.3.4.3. Replay events

3.4.3.4.4. Rebuild production database

3.5. Why

3.5.1. Pros

3.5.1.1. More efficient design

3.5.1.2. Simpler within each stack

3.5.1.3. Optimized perofrmance

3.5.2. Cons

3.5.2.1. Inconsistent across stacks

3.5.2.2. Type 2 is more complex

3.5.2.3. Type 3 might be overkill

4. Functional Organization

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

4.2. Building Analogy

4.2.1. Functional Organization

4.2.2. Component Organization

4.3. Silverware Examples

4.3.1. You put all "Eating Utensils" together

4.3.1.1. Forks, Spoons, Knives

4.3.2. You don't put all the forks together

4.3.2.1. Eating Fork, Pitch Fork, Tuning Fork...

4.4. Why

4.4.1. Pros

4.4.1.1. Spatial Locality

4.4.1.2. Easy to navigate

4.4.1.3. Avoid vendor lock-in

4.4.2. Cons

4.4.2.1. Lose framework conventions

4.4.2.2. Lose automatic scaffolding

4.4.2.3. Categorical is easier at first

5. Microservices

5.1. Domains

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

5.1.1.1. contexts could be

5.1.1.1.1. Sales associate

5.1.1.1.2. vs

5.1.1.1.3. Customer

5.1.1.2. Problems

5.1.1.2.1. validation is different on each side

5.1.1.2.2. properties we want to show are different

5.1.1.2.3. etc

5.2. Define

5.2.1. Subdivide system

5.2.2. Bounded contexts

5.2.3. Small teams

5.2.4. Independent

5.2.5. Similar to SOA

5.3. Why

5.3.1. Pros

5.3.1.1. Less cost for large domains

5.3.1.2. Smaller teams

5.3.1.3. Independence

5.3.2. Cons

5.3.2.1. Only for large domains

5.3.2.2. Higher up-front cost

5.3.2.3. Distributed system costs

6. Code Demo

7. Resources

7.1. Uncle Bob Clean Code Videos

7.2. Domain-Driven Design

7.2.1. Eric Evans

7.2.2. Book

7.3. Greg Young & Udi Dahan event sourcing articles

7.4. Presenter's website

7.4.1. matthewrenze.com

8. Presenter

8.1. Matthew Renze

8.2. @matthewrenze

8.3. [email protected]

8.4. Independent Software Consultant

8.5. Pluralsight Author

9. Software Architecture

9.1. High-level

9.2. Structure

9.3. Layers

9.4. Components

9.5. Relationships

10. Levels of Architectural Abstraction

10.1. Systems

10.2. Sub-Systems

10.3. Layers

10.4. Components

10.5. Classes

10.6. Data and Methods

10.7. (think in a pyramid)

11. Messy vs Clean

11.1. Messy

11.1.1. Looks like spaghetti code

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

11.1.3. Complex

11.1.4. Incosistent

11.1.5. Incoherent

11.1.6. Ridged

11.1.7. Brittle

11.1.8. Untestable

11.1.9. Unmaintainable

11.2. Clean

11.2.1. Lasagna

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

11.2.3. Simple

11.2.4. Understandable

11.2.5. Flexible

11.2.6. Emergent

11.2.7. Testable

11.2.8. Maintainable

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

12. Why Clean Architecture?

12.1. Cost/Benefit

12.2. Minimize Cost to Maintain

12.3. Maximize Business Value

12.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

12.5. POINT

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

12.5.1.1. focused first on essential, details can come later

12.5.2. Essential

12.5.2.1. Domain

12.5.2.2. Use Cases

12.5.3. Details

12.5.3.1. Presentation

12.5.3.2. Persistence