Book Image

Hands-On Domain-Driven Design with .NET Core

By : Alexey Zimarev
5 (1)
Book Image

Hands-On Domain-Driven Design with .NET Core

5 (1)
By: Alexey Zimarev

Overview of this book

Developers across the world are rapidly adopting DDD principles to deliver powerful results when writing software that deals with complex business requirements. This book will guide you in involving business stakeholders when choosing the software you are planning to build for them. By figuring out the temporal nature of behavior-driven domain models, you will be able to build leaner, more agile, and modular systems. You’ll begin by uncovering domain complexity and learn how to capture the behavioral aspects of the domain language. You will then learn about EventStorming and advance to creating a new project in .NET Core 2.1; you’ll also and write some code to transfer your events from sticky notes to C#. The book will show you how to use aggregates to handle commands and produce events. As you progress, you’ll get to grips with Bounded Contexts, Context Map, Event Sourcing, and CQRS. After translating domain models into executable C# code, you will create a frontend for your application using Vue.js. In addition to this, you’ll learn how to refactor your code and cover event versioning and migration essentials. By the end of this DDD book, you will have gained the confidence to implement the DDD approach in your organization and be able to explore new techniques that complement what you’ve learned from the book.
Table of Contents (14 chapters)

Summary

In this chapter, we took CQRS to a whole new level and learned how to query data that we initially stored as streams of events. Since event streams are hard to query on demand, we need to build snapshots of data that we can show to our users. The power of event-sourced read models is that we can build virtually an unlimited number of use case-specific read models, with very precise sets of data. We could avoid things such as joins across object collections or tables, or even between remote services. We can remove all read models at once and rebuild them from scratch, using only events. If we somehow created our projection in a way that it showed the wrong data on screen, then we can quickly catch the bug and fix the read models by removing and rebuilding them.

Of course, everything has its trade-offs. Sometimes, we can't receive all the data that we need for a read...