Modern Software Architecture: Domain Models, CQRS, and Event Sourcing

This course covers DDD analysis patterns helpful in discovering the top-level architecture of a business domain. Architects and developers will find details of implementation patterns such as Domain Model, CQRS, and Event Sourcing.
Course info
Rating
(662)
Level
Intermediate
Updated
Jul 23, 2015
Duration
4h 25m
Table of contents
DDD at a Glance
Discovering the Domain Architecture through DDD
The DDD Layered Architecture
The "Domain Model" Supporting Architecture
The CQRS Supporting Architecture
Event Sourcing
Designing Software Driven by the Domain
Description
Course info
Rating
(662)
Level
Intermediate
Updated
Jul 23, 2015
Duration
4h 25m
Description

This course covers DDD analysis patterns helpful in discovering the top-level architecture of a business domain. Architects and developers will find details of implementation patterns such as Domain Model, CQRS, and Event Sourcing.

About the author
About the author

Author of many popular books that helped the professional growth of thousands of .NET developers, Dino serves as the CTO of Crionet and focuses on web and mobile solutions for sport events. He’s also a JetBrains technical evangelist and member of the team that manages WURFL.

More from the author
UI Best Practices Playbook for ASP.NET MVC
Intermediate
2h 42m
3 Apr 2018
UX-driven Software Design
Intermediate
3h 30m
31 Mar 2017
Architecting Device-Driven Web Solutions
Intermediate
4h 0m
26 Sep 2014
Section Introduction Transcripts
Section Introduction Transcripts

Discovering the Domain Architecture through DDD
Welcome back to Pluralsight. It's module two of Modern Software Architecture and this is Dino Esposito. As discussed in the first module, today most of the value of DDD is in the tools it provides for a domain analysis. Domain-driven design is about tackling the complexity in the very heart of software and it's about organizing the business logic. To achieve this goal, it's crucial to focus first on the analysis of the domain and keep things like layers, object models, and persistence for later. This module provides a walk-through of the DDD analysis practices. In particular, we'll focus on concepts like the ubiquitous language, the bounded context, and context mapping, the pillars of domain-driven design. The ubiquitous language defines a common vocabulary to express models and processes. Bounded contexts are segments of the domain that is preferable to treat separately, and finally, all identified contexts and their explicit relationships form a map, which is where your domain analysis efforts come to an end.

The DDD Layered Architecture
Hi everybody, and welcome to module three of the Pluralsight course on Modern Software Architecture, Dino Esposito speaking. This module is essentially another view of the layered architecture, the multilayer segmentation of a software system that Eric Evans first introduced in a book that presented domain-driven design into the world. At the end of the day, the layered architecture is a revision of the classic, and in a certain way, iconic, 3-tier architecture, the one made of presentation, business, and data access. In this module, I'll explain ____ that segments of a layered architecture and how they relate to the aforementioned, but so far quite indefinite concept of a domain model. So we'll first talk about layers and tiers, and the separation of concerns. Next, we focus on common patterns for organizing the business logic. And finally, we'll discuss the four layers of the architecture, presentation layer, application layer, domain layer, and infrastructure.

The "Domain Model" Supporting Architecture
Hi everybody. Welcome to module four of Pluralsight's course on Modern Software Architecture, Dino Esposito speaking. With module four, the course gets into the part that analyzes in detail a few architectural approaches to effective design and implementation of the domain layer, and the first supporting architecture we consider is domain model. The domain model supporting architecture was originally introduced in Evan's book about domain-driven design as a sort of prescription for implementing the domain layer, and the prescription revolved around two main elements, an object-oriented model and a set of services. This module discusses in the end the foundation of an object-oriented model for describing the business domain, domain services, and then it moves farther to look into more recent developments, such as the use of events, and in general, a more task focused view of the business domain.

The CQRS Supporting Architecture
Hi everybody, welcome to module five of Pluralsight's course on modern software architecture, Dino Esposito speaking. About a decade ago, when Eric Evans first introduced domain-driven design, the world of software was such that an object-oriented model to fully express the intricacies of the business domain sounded like a really compelling idea. But years of practice instead have proved that the task was more difficult than the initial estimation. So, for years as developers we faced a lot of complexity and we thought that it was all about the inherent complexity of the business model. So with domain-driven design, we focused on practices to facilitate the learning of the business domain, and now we are realizing that there is more to it, and we are seeing a new approach emerging. Today there is the classic way of expressing the business domain through an object-oriented model, all-encompassing, and there is a new way. The new way goes under the name of CQRS, which is the acronym for command query responsibility segregation, and it's all about separating commands from queries using distinct application stacks. The module, this module, discusses the foundation of CQRS and identifies three flavors of it that I like to call in a growing order of complexity and sophistication, as Regular CQRS, Premium CQRS, and CQRS Deluxe.

Designing Software Driven by the Domain
Hi everybody, and welcome to module seven, the final module of Pluralsight's course on Modern Software Architecture. As usual, Dino Esposito is speaking. Domain-driven design, DDD, has been the first serious attempt to systematize design and development of software systems. In this class, I went through the inspiring principles and common practices of DDD and discussed a few supporting architectures for the actual implementation of systems. What does it mean? Design driven by the domain, a larger version of the acronym DDD. What's the exact meaning we should intend? Abstractly speaking, it indicates the idea of building a piece of software that mirrors the business domain. In the beginning, domain-driven design came with the idea of having an object model like the business domain. In this class, we also discussed how focusing on tasks makes it easier to model the system. Finally, in a time in which users are much less passive and forgiving as they were only a decade ago, the role of the user interface and its impact on the user is critical. So, in this final module I'll offer a software wrap up about domain-driven design, and also discuss ways it applies to legacy code, task-based design, and user experience.