Summary: The book can be divided into 4 parts: 1) Introduce Terms and Concepts, 2) How to do Domain Driven Design, 3) Case Studies and Illustrations, and 4) How to run sessions that actually get you to the design. It is important to understand that this book is designed to explain the book that explains Domain Driven Design (DDD). To that end, it does a very good job at making a difficult and complex topic digestible. It is like reading the cliff notes to an analysis of Hamlet. It is removed from the material, but introduces the material nicely.
Top 3 things I learned
- Break the problem up into Bounded Contexts. Within those Bounded Contexts develop a Ubiquitous Language.
- There are many ways to communicate across contexts with various pros and cons.
- Event storming is an amazing technique to quickly develop and find the answer.
Chapter 1: DDD for me (10%)
Summary: One thing to understand about this book. It is 144 pages of explaining the author’s other book which explains Eric Evan’s original book on this topic. He has made the material very digestible, but this is an entry level book into an advanced topic.
TERM: The “Task-board Shuffle” — a “To-Do” list placed in a backlog and them moved across several lanes until it gets to done.
CONCEPT: Knowledge Acquisition. Something Scrum is very good at, but rarely gets to act on. Learning (knowledge acquisition) must flow back into the design, however the emphasis in usually on cranking out features instead of iteratively developing the solution. This is done through experimentation and is referred to as buying information.
QUOTE: Design is inevitable. The alternative to good design is bad design, not no design at all. – Douglas Martin
CONCEPT: Design.
- Strategic Design. Segregate your domain models using the strategic design pattern called Bounded Contexts, you then develop a ubiquitous language as your domain model within an explicitly bounded context
- Subdomains and how they help with unbounded complexity of legacy systems
- Tactical design through aggregate patterns
Chapter 2: Strategic Design with Bounded Contexts and the Ubiquitous Language (20%)
SUMMARY: This chapter introduces the fundamental information that you need for the rest of the book so pay attention to the concepts presented here. If you don’t follow these instructions then you run the risk of getting a big ball of mud, aka monolith. Keep things separate by bounded contexts because the organization exists for some reason and the solution exists for those same reasons.
TERM: Bounded Context is a semantic contextual boundary. Wishing the boundary each component of the software model has a specific meaning and does specific things. Components inside are context specific and semantically motivated. You can think of them as being language barriers.
TERM: Problem space. High level strategic analysis and design steps within the project’s constraints. Context maps work well here.
TERM: Solution space. Where you implement the solution that your problem space discussions identify as your Core Domain.
TERM: Ubiquitous Language. Both spoken among the team members and implemented in the software model. It is rigorous, strict, exact, stringent, and right. Formed from nouns.
TERM: Core Domain. The Bounded Context that is being developed as a key strategic initiative of your organization. It distinguishes your organization from others. It addresses a major line of business.
CONCEPT: Bounded Context
- Own source code repo
- Own database
- Teams do not cross boundaries
CONCEPT: DDD embraces the differences in the organizations by segregating the differing types into Bounded Contexts.
CONCEPT: Fundamental strategic design. Ask what is core? Focuses us to focus.
CONCEPT: Difference between Product Owner and Domain Expert. PO (Backlog, prioritization) and Domain Expert (Business Context Focus)
IDEA: Focus on the business complexity, not technical complexity.
CONCEPT: Scenarios. Describe how the very real software model components are used. Can be a narrative or Given-When-Then
Chapter 3: Strategic Design with Subdomains (10%)
SUMMARY: A extremely small chapter to introduce an important, but simple concept of SubDomains.
CONCEPT: Optimal is one SubDomain to a Bounded Context and one Bounded Context to a SubDomain
TERM: SubDomain: A single logical domain model. A SubDomain has one or more Domain Experts. A Bounded Context should align 1:1 with a single SubDomain.
CONCEPT: Types of SubDomains
- Core Domain. Top Tier. Strategic Investment
- Supporting SubDomain. 2nd String to the Core
- Generic SubDomain. More off-the-shelf programing / Tier 3 program
Chapter 4: Strategic Design with Context Mapping (15%)
SUMMARY: One of the most important chapters. You can effectively breeze through chapters 1-3, but slow down for this one. You need the concepts and terms from chapters 1-3 to understand this one. The earlier concepts are not difficult to understand but are fundamental.
TERM: Context Mapping. The integration between Bounded Contexts. Explains how language 1 and language 2 are translated. At a high-level there are 2 types: Team and Technical (can be blended)
CONCEPT: Kinds of Context Mappings
- Partnership.
- Relationship between 2 teams
- Each team is responsible for one Bounded Context
- Aligns 2 teams with a dependent set of goals
- Succeed or fail together
- Thick mapping line, level of commitment is high
- Tough to maintain over the long term
- Should last only as long as there is an advantage
- Shared Kernel
- Share a small but common model
- Must have open communication
- Constant agreement
- Customer-Supplier
- Supplier is Upstream (U) and Customer is Downstream (D)
- Customer can plan with Supplier
- Ultimately Supplier determines what the Customer will get and when
- Conformist
- Upstream and Downstream, but the upstream has no motivation to support the specific needs of the downstream.
- Downstream needs to accept the upstream model as is
- Anticorruption Layer
- Most defensive context mapping relationship
- Downstream creates a translation layer
- Layer isolates downstream from upstream and downstream
- Costly
- Open Host Service
- Defines a protocol or interface that gives access to your Bounded Context as a set of services
- Protocol is open
- Services are well documented and a pleasure to use
- Much easier to consume that other types of mapping
- Service is provided by Upstream
- Published Language
- Well-documented information exchange language enabling simple consumption and translation
- Confidence in the translation
- XML/JSON
- Published language is provided by upstream
- Separate Ways
- One or more Bounded Contexts will not produce significant payoff by consuming various ubiquitous languages.
- More work than is worth it and each go their own way
- Big Ball of Mud
- Avoid like the plaque
- Why avoid?
- Growing number of aggregates cross-contaminate because of unwarranted connections and dependencies
- Changes have a ripple effect across the model and you play whack-a-mole
- Tribal knowledge and heroics are needed
CONCEPT: Ways to use Context Mapping
- RPC (Remote Procedure Calls) with SOAP (Simple Object Access Protocol).
- Strong coupling
- Lacks robustness
- Looks easy, but reality (network issues) make it difficult
- RESTful HTTP
- Tends to fail for the same reasons as RPC, network and service failures or unanticipated latency
- Messaging
- One of the most robust forms of integration because you remove much of the temporal coupling
- Idempotent Receiver
Chapter 5: Tactical Design with Aggregates (15%)
SUMMARY: This chapter moves from the strategic to the tactical and talks about the use of Aggregates. A rather long chapter, but one of the least useful chapters. The chapter serves as a bridge to chapter 6 and a summary of a very complex topic. I felt that the chapter was either too short (not enough detail) or too long. It introduces the topic but does not get into enough detail to really make it useful other than to let you know there is a lot more to learn on this topic.
TERM: Entity. An entity models an individual thing. Entity will be mutable, it is unique and an individual.
TERM: Value Object. Models an immutable conceptual whole. It does not have a unique identity and equivalence is determined by comparing the attributes encapsulated by the value object.
TERM: Aggregate. Composed on one or more Entities. One Entity is the Aggregate Root. May also have Value Objects composed on them. Each Aggregate forms a transactional consistency boundary. Here is the key –> if the Aggregate was not stored in a whole and valid state, the business operation that was performed would be considered incorrect according to business rules.
CONCEPT: Aggregate Rules of Thumb
- Protect business invariants inside Aggregate boundaries. What must be consistent when a transaction is committed.
- Design small Aggregates. Single Responsibility Principle.
- Reference other Aggregates by identity only
- Update other Aggregates using eventual consistency.
CONCEPT: Anemic Domain Model. Your objects only have getters and setters no real business behavior.
Chapter 6: Tactical Design with Domain Events (10%)
SUMMARY: I see a lot of value with DDD at the Strategic level, I’m not convinced of its value at the tactical level.
Chapter 7: Acceleration and Management Tools (20%)
SUMMARY: An amazing chapter. The first 100 pages of the book are very high level, theory, this is all application. Roll your sleeves and get to work.
CONCEPT: Event Storming. A rapid design technique. Tactile, focuses everyone on events and business processes, very visual, very fast, very cheap, you will have breakthroughs in understanding
- Storm out business processes by creating a series of domain events
- Create commands that cause domain events
- Associate entity/aggregate/data with commands
- Draw boundaries w/arrows for information flow
- ID views that your users will need
CONCEPT: Colors for the process
- Orange — Domain Events
- Purple/Red — Problems
- Lilac
- A process that is the outcome of a domain event.
- Command that causes a process to run
- Light Blue — Name of a command that causes an event
- Bright Yellow — Specific User Role
- Pale Yellow — Aggregates / Entity
- Pink — Temp boundaries / names of Bounded Contexts
- Green — Wireframes / View needed
CONCEPT: Storming out business processes
- Create domain events based on business processes not data
- Write name of domain event on a sticky note. Verb in past tense.
- Stickies on modeling surface in the order they occur
- Use vertical space to represent parallel processing
- ID problems with purples/red sticky notes
- Sometimes the outcome of a domain event is a process, use lilac. Model a fine grained Domain Event only if it is important to your Core Domain.
CONCEPT: Create Commands that cause each Domain Event. Should be stated in the imperative
- Name of the command that causes the corresponding domain event. Use light blue.
- Place to the left of the Domain Event that it causes. They come in pairs Command/Event
- If a specific user role, then yellow sticky on lower left corner of light blue command
- Sometimes a command causes a process to run, put command on Lilac sticky. Draw a line with an arrowhead from Command to the named Process.
- It is possible that there are one command for multiple domain events
CONCEPT: Associate Entity/Aggregate on which the Command is executed and that produces the Domain Event outcome. This is the data holder where Commands are executed and Domain Events are emitted.
- Put all Aggregates (Entities/Data) on a pale yellow
- Place behind and slightly above Command and Domain Event pairs
- Aggregates happen often, duplicate them behind each pair because you are modeling the business process and the business process occurs over time
CONCEPT: Draw boundaries and lines with arrows to show flow
- Boundaries may be found under divisions
- Black marker pens to draw, show context and other boundaries. Solid lines for Bounded Contexts and dashed liens for Subdomains.
- Can use pink stickies to create temp boundaries until sure
- Put notes / names of Bound Contexts inside on Pink Stickies
- Draw lines with arrowheads to show the direction of Domain Events
CONCEPT: Identify various user views
- Green stickies to id important wireframes
- Put users (bright yellow)
CONCEPT: Other tools
- Specification by Example (Gojko Adzic’s book)
- Impact Mapping (another Gojko Adzic book)
- User Story Mapping by Jeff Patton
QUOTE:
Knowledge Acquisition is both a Scrum tenet and a major goal of DDD, but is largely ignored in exchange for relentless delivery with Scrum
CONCEPT: SWOT Analysis
- 4 quadrants
- Strengths : what you have going for you
- Weaknesses: anything that can be improved on
- Opportunities: what you can focus your energy on
- Threats: obstacles that you must surpass
My Travels Through Agile Software Development 