You’ve studied up on DDD, CQRS, and Event Sourcing… now what?
Naturally, you want to apply them to a real-world Domain - a complex software project that you are working on. This is when you realize how little you actually know about applying DDD. Will you ever truly grok DDD?…
You start to feel like you can’t figure out which concepts go into which Bounded Contexts. You have trouble finding clear consistency boundaries. Your team feels like they consistently fail at modeling Aggregate Roots.
The issues show up when you’re writing the code, but the root cause tends to be missing concepts from your Domain.
“We wouldn’t have had all this trouble designing the Domain Model if we had known about that Domain Concept in the first place… it just didn’t come up when we met with the Domain Experts.”
Don’t get stuck breaking DDD rules because you don’t know your Domain
You may feel like you’ve spent more than enough time with the Domain Experts, but when you attempt to “modelize” parts of your Domain - you find yourself breaking rules, introducing accidental complexity, and using patterns that don’t smell right.
Start being confident in your modeling decisions
Imagine being able to map Domain Concepts to their correct Bounded Contexts on the first try. If putting Concepts into the right Bounded Contexts was a trivial exercise, you could move on to the fun stuff - coding and shipping a good Domain Model.
What if your team was always on the same page when it came to modeling good Aggregate Roots? Everyone on your team would know how to come up with, and agree on a strong Domain Model.
What would it be like to have a technique that helped you confidently define Aggregate Roots, Consistency Boundaries, Bounded Contexts, Commands and Events, etc.? Domain Concepts would rarely slip through the cracks. You’d know where to accept eventual consistency, ensure immediate consistency, and how to set SLAs accordingly.
What if could learn some valuable modeling techniques within the next couple weeks, saving you months of back and forth with Domain Experts?
Use the fundamentals of DDD to your advantage
True, Domain Models aren’t born free of defects. With the right fundamentals, you can build a Domain Model that is alive and malleable. Your Domain Model can be a living, breathing part of your application. It can be built so that it welcomes changes, because let’s face it - the business’s core strategies will change.
Crunch knowledge into a thriving Model
Learn how to crunch knowledge into a high-quality Domain Model with my book: Applying Domain Driven Design with CQRS and Event Sourcing. Make the most of the time you have with the Domain Experts with a technique called EventStorming.
Turn your EventStorming results into a CQRS/Event Sourcing based prototype quickly. Show the business that you know how to find bottlenecks and solve the right problems with your software.
Follow along as we model a real-life business scenario
While this information is available on my blog, this book will give you a more contiguous, searchable, offline-able format to see how DDD is used for complex Domains.
You’ll get a glimpse into the story of a start-up that is looking for help in solving problems that are only found in their specific Domain. You’ll be able to see how you can apply DDD fundamentals to any Domain and how to translate the results into working code.
Scroll down to see the full table of contents…
Click here for a free sample chapter…
See what it takes to build an end-to-end prototype with DDD
All you have to do is buy my book: Applying Domain Driven Design with CQRS and Event Sourcing for an introductory price of $29 and you’ll learn how to get from Point A to Point B with learning a Domain, modeling it, and implementing a working prototype… all in a matter of hours.
Table of contents…
Chapter 1
The Domain
Big Picture EventStorming
Our first Domain Event: "Coffee Purchased"
Momentum
Unlimited Space
Discovering the Domain through EventStorming
The Whole Picture
Discovering Hotspots through EventStorming
Discovering Commands through EventStorming
Chapter 2
Design Level EventStorming
Bounded Contexts
Competitive Advantage
Complexity and Cost
Design Level EventStorming Continued
Roast Planning
Chapter 3
Implementing an Event Sourced Aggregate Root
Vertical Slice
The Aggregate Root Base Class
Command Handlers
Application Service to Command Handler
The Event Store Repository
Persisting Aggregate Events
Before
After
Chapter 4
Testing Event Sourced Aggregate Roots
Executable Specifications
Chapter 5
Read Models
The Bus
Sending Commands to the Bus
Testing the Bus
Sending Events to the Bus
Chapter 6
Projection
Handling Events on the Read Side
The Read Model Facade
User Interface
Conclusion