Domain-Driven Design (or DDD for short) is one of the most popular approaches
to software development, and that's for a very good reason.
As described excellently by Martin Fowler, it "is an approach to software
development that centres the development on programming a domain model with a
rich understanding of the processes and rules of a domain".
Building software that way, especially when dealing with a complex domain,
leads to aligned business people and developers and better software that does
precisely what the business needs. Ever since its formal definition by
Eric Evans all the way back in 2003, developers have used it to create software
based on a well-developed model of design. In this Getting Started course,
Amichai Mantinband will break down Domain-Driven Design into a very easily
digestible concept using his real-world experience.
Course Curriculum
5h 11m 11 sections
Welcome
01:11Free preview
What will you learn in this course?
02:13Free preview
Who is the course for and prerequisites
03:10Free preview
What is Domain-Driven Design?
01:27
What is a Domain?
04:26
Why you should learn and practice DDD
02:19
The two parts of DDD
04:56
Section Recap
01:47
The domain we’ll be exploring
06:06
The domain’s Ubiquitous Language
04:30
Ubiquitous Language as a tool for detecting Domain Objects
03:41
The domain’s invariants
03:00
Enforcing invariants
02:44
Creating the domain objects
05:20
Invariants as Unit Tests
10:41
Enforcing Invariants that rely on dependencies
12:22
The Result Pattern
10:08
Section Recap
02:10
What are Tactical Patterns?
03:15
What is Tactical Design?
03:33
Entities
03:49
Implementing the Entity base class
02:23
Value Objects
07:29
Implementing the Value Object base class
02:39
Aggregates
06:02
Shifting the focus to Aggregates
06:16
Implementing the Aggregate base class
01:09
Structuring the Domain Layer around Aggregates
08:34
Domain Services
05:32
Factories
03:34
Implementing a Static Factory Method
05:05
Repositories
04:40
Disconnected Domain Models
01:40
Repositories and EF Core
03:18
Implementing a Repository
03:14
Section Recap
01:16
Accessing the Domain Layer via a web API
04:49
A system without Domain Events
06:45
Eventual Consistency
01:15
What is a Domain Event?
05:27
The Domain Event Sausage Factory
06:43
Implementing a Domain Event
06:41
Section Recap
01:23
Domain Modeling & Analysis Paralysis
01:41
Domain Model Identity Uniqueness
02:28
Domain Object Deletion
03:38
One Aggregate Per Transaction
03:21
Reference Between Domain Models
03:43
Section Recap
00:55
Application Services vs Domain Services
05:11
Transactional vs. Eventual Consistency
05:08
Rich vs. Anemic Domain Models
03:57
Always Valid vs. Not Always Valid
02:32
Persistence Ignorance
01:08
Section Recap
01:19
What is Strategic Design?
04:41
Sub-Domains
03:30
The 3 types of Sub-Domains
03:40
Context Mapping and Context Maps
04:14
Context Map example
04:43
Team Relationships
01:44
Context Map Patterns
03:07
Section Recap
01:18
Bounded Contexts
05:29
Bounded Contexts vs. Sub-Domains (Problem vs. Solution Space)
05:17
Exploring our Domain’s Bounded Contexts
04:06
Exploring relationships between our Bounded Contexts
06:10
Defining our Context Map
05:00
Section Recap
01:09
What are Integration Events?
02:46
The chain of Integration and Domain Events
04:21
Using a Message Broker for distributing Integration Events
04:29
Error handling when publishing Integration Events
03:56
The Outbox Pattern
04:25
The Integration Events Sausage Factory - Outbox Writer
04:18
The Integration Events Sausage Factory - Integration Event Publisher
01:56
The Integration Events Sausage Factory - Consuming Integration Events
Amichai Mantinband is a Software Engineer at Microsoft and a .NET content creator. He works on large-scale, distributed systems within Microsoft Office, serving over 100 million daily users. He is a speaker at official .NET conferences, and within Microsoft, he authors and teaches software architecture courses. Amichai is the author of NuGet packages ErrorOr & Throw and has a .NET programming YouTube channel covering advanced topics such as design patterns, architecture, and best practices.