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
Tweet