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