(Start) Making Sense Of DDD-Based Software Engineering

Preface

1. Could this book be valuable for you?
2. What are the 3 main goals of this book?
3. Why I wrote this book
4. Who should read this book?
5. How to navigate this book
6. Some final preliminary remarks
7. Disclaimer about Terminology used in this book
8. About the author

Part 1: The main DDD concepts from the bird’s eye view

1. Design driven by the Domain Model
2. A Model that builds upon the Ubiquitous Language
3. A Single Model
4. A “Rich” Model
5. Knowledge Crunching: Model Analysis Sessions that include the Developers
6. Continuous Learning
7. Splitting the Enterprise Model on several Levels of Abstraction
8. Strategic Design vs Tactical Design plus Application Layering

Part 2: Dissecting Strategic Design

1. Making sense of the Domain- and Subdomain concepts
2. What is a Domain?
3. The Default Case: One Organization, One Domain
4. What is a Subdomain?
5. Domain vs Subdomain example 1: Insurance company
6. Core (Sub-)Domain, Supporting Subdomain, Generic Subdomain
7. Dissecting the concept of Bounded Contexts and the Context Map
8. Bounded Context Identification Criteria
9. What is a Context Map?
10. Challenging the Bounded Context Criteria by Examples
11. Bounded Context Design Example 1: A Company selling digital products
12. Bounded Context Design Example 2: Transactions in the banking domain
13. Bounded Context Design Example 3: Orders within the Subdomain “Securities Trading”

Part 3: Backend Application Architecture for Clean Bounded Contexts

1. The Layered Architecture of purist DDD-compliant Applications
2. The missing Technology-specific Invocation Layer
3. Responsibilities of the Application (Service) Layer
4. Introducing Ports & Adapters
5. Ports & Adapters in a nutshell
6. Aligning Ports & Adapters with DDD
7. Why Ports & Adapters at all?
8. Dissection: What exactly is the “Domain-Layer”?
9. What is a DDD “Service” a.k.a. “Domain Service”?
10. Challenging Domain Services using Evans’ FundsTransferService example
11. Challenge: Shall Domain Entities be allowed to invoke services?
12. Dissection: The Domain Layer and Isolation
13. What is a DDD Repository?
14. Challenge: Strict vs. “pragmatic” isolation: Unification of persistence- and domain model?
15. Definition of “Clean Bounded Context”

Part 4: Dissecting Tactical Design

1. What is a Domain Entity?
2. What is a Value Object
3. Dissecting Aggregate Design: Aiming for “Clean Aggregates”
4. The classical Order and OrderItem Aggregate example
5. Why is the aggregate design of such central importance?
6. Aggregate Design Rules
7. Practical Aggregate Design Guidance via the “Clean Aggregate Design Checklist”
8. The “Clean Aggregate Design Checklist”
9. Other general Domain Model Design Rules
10. Design Rule “Make the implicit explicit”
11. Design Rule “Prefer concrete over generic models in the Core Subdomain”
12. Wrap a Collection of Value Objects into an expressive Wrapper type
13. What is a DDD Factory?

Part 5: Challenging the Aggregate Consistency Boundary Rule

1. Applicability of “Eventual Consistency” in cases of Multi-Aggregate Write Operations
2. Why Clients may shy away from applying Eventual Consistency
3. Introduction to the “New Customer submits his first Order” example
4. Eventual Consistency Variation 1: Domain Event-based implementation with strict Aggregate Separation
5. Structuring the flow of Domain Events and Transactions
6. The Technical Infrastructure for using Domain Events
7. Introducing the Outbox Pattern
8. Introducing the Payload Model for Domain Events
9. Technology Candidates for sending and receiving domain events
10. Code Examples from the Webshop Backend Application
11. Why do we also need some kind of Batch Application?
12. Eventual Consistency Variation 2: Using a Business Process Engine (“BPE”)
13. BPE Architecture considerations
14. Variation 2.A: Embedded BPE
15. Variation 2.B: Centralized BPE
16. Example Architecture with 3 Bounded Contexts, BPE and Domain Events
17. Eventual Consistency Variation 3: Violating the Consistency Boundary Rule
18. Introducing the “Cross-Aggregate Application Service”
19. Eventual Consistency Conclusion
20. Is Eventual Consistency generally worth the effort?
21. What about Event Sourcing and Event Replay?
22. Which Eventual Consistency Variation is preferrable?
23. The Bottom Line
24. A brief Note about other Orchestration Techniques
25. Challenging Strict Isolation with Concurrent Modification Scenarios
26. Option 1: Partial Update
27. Option 2: Full Entity Replacement via EntityManager.merge()
28. Conclusion

Part 6: Tactical Design Example 2: The Football Association Management System (“FAMS”)

1. Why you should work through this part
2. A little context about the client
3. Knowledge Crunching Session 1: The Foundations
4. Starting off with an initial Big Picture of the Domain Model
5. Challenge: How to keep domain models clean in the face of ternary associatons
6. Challenge: Why LeagueDefinition and League are separate Aggregates
7. Challenge: Clean Code vs Ubiquitous Language
8. Challenge: How about letting Domain- and Persistence Aggregates deviate for Ternary Associations?
9. Challenge: How about bypassing the Domain Layer for simple CRUD Use Cases?
10. Revisiting the Ternary Association “Season-Team-Player”
11. Challenge: How practical is Evans’ “One Model”-Paradigm?
12. Challenge: Choosing the best approach for the 2nd Knowledge Crunching Session
13. Model-driven Knowledge Crunching vs Event Storming vs Effective Use Cases
14. Knowledge Crunching Session 2: Big Picture Event Storming
15. Conclusion of the Big Picture Event Storming Session
16. Knowledge Crunching Session 3: Deep-dive into the Player Lifecycle
17. Challenge: Iteratively improving the Player Aggregate
18. Revision 1 of the Player Domain Model
19. Revision 2 of the Player Domain Model
20. Designing a state diagram for the Player Entity
21. Analyzing the Invariants for Application and Player
22. Revision 4 of the Player Domain Model
23. Revision 5 of the Player Domain Model or: Isn’t Transfer also a kind of Application?
24. Revision 6 of the Player Domain Model: Explicit Application-Types
25. Challenge: Should we replace the State Pattern in the Player Entity
26. Revision 7 of the Player Aggregate Model: Splitting up the Player Entity
27. Challenge: The impact of concurrent modification scenarios on the aggregate design
28. Example Concurrent Modification Scenario for a Registration Application
29. Challenge: Applying the Clean Aggregate Design Checklist
30. Is RegistrationApplication an Aggregate Root Entity?
31. Are the FollowupApplication Types Aggregate Root Entities?
32. Aggregate Design Showcase for the Team Entity Cluster

Part 7: Writing “Clean Domain-driven Code”: Examples from the FAMS System

1. The Basics: How to create Aggregate Instances in a clean and convenient way
2. Example 1: Implementing the Use Case “Initiate Player Registration”
3. The PlayerResource REST-Service
4. The InitPlayerRegistrationApplicationService
5. The creation of the transient Player domain object
6. Example 2: Implementing the Use Case “Add SquadMember to Lineup”
7. The AddNominatedPlayerToLineupApplicationService
8. The AssertPlayerCanBeAddedToLineupDomainService
9. Part 7-Conclusion about “Clean Domain-driven Code”

Part 8: Further Architectural Topics

1. Communicating with other Bounded Contexts
2. DDD with Third-Party- or Legacy Core Systems
3. An architectural Variation: Spring Modulith + jMolecules

Part 9: The Overall Conclusion

Appendix: Structuring the Analysis with “Effective Use Cases”

References