Domain-Driven Design: The Last Explanation You'll Ever Need

In this Domain-Driven Design tutorial, we are going to learn all the details such as strategic & tactical design, domain models, bounded contexts, entities & value objects, and everything else that one would need to know about DDD. We'll also take a look at a sample code to see what the structure would then look like.

======⚡⚡⚡======

📚 Resources:

🕒 Timestamps:
(0:00) Intro
(0:34) What is DDD?
(1:31) Strategic design
(6:48) Tactical design
(8:00) Entity
(9:17) Value object
(10:20) Aggregate
(17:16) Communication between Bounded contexts
(18:38) Anemic vs Rich model

And don't forget to subscribe for more videos like this 😊

[valikirr]

First, Big like for explanation and your contribution.

I disagree that controllers reside in the application layer. They must be on presentation layer. We are exposing API, presenting API to the outer world if you wish. In some full stack frameworks presentation layer could also include UI. Application layer is the orchestrational layer between domain, infrastructure and presentation layers. The rest is explained pretty well. But honestly, I strongly encourage people to read book about DDD, because you can not fit all the knowledge and details in 20 minutes. People hold 1-2 day workshops to teach about DDD. So the ones who are reading this, don't directly put "I know DDD" in your CV after watching this video :D

[mofekayode]

Please start a playlist/ course where you build a mock application using Domain-Driven Design

[sinaahmadpour]

Probably one the best and simplest explanations for DDD. Thanks for the great content.

[atuljoshi]

Good video just one thing I think you might be merging is the application and domain services all together.
Generally, Domain Services should be used when business rules involve coordinating multiple aggregates. If the logic pertains to a single aggregate, it should be encapsulated within that aggregate’s entity methods.
So if your controller are below adaptors and act as application layer use-case it should handle the orchestration for the infra structure layer or other domain or application service.

I would keep the domain service clean and pure. And domain creation can be done via domain factory which can call the service dependency for any infra for any lazy loading or validating from the db, but no persistence from domain service.

- Domain Services contain pure business logic and should not deal with persistence (database operations).
- Application Services handle use cases, orchestrate domain services, and interact with repositories.

[sebastianpopa]

good and concise, I'll note that the anemic model description at the end is a little, well, anemic. While it does touch on the issue, it doesn't underline it enough, Martin Fowler on his site has a section on this issue. Also, the idea that entities can "span multiple bounded contexts" is odd to me, the point of bounded contexts is to clarify what things with possibly same names mean. So while the "name" might be same or similar, their "meaning" will be different, hence a clarification is required. A "customer" in "account" bounded context (user, password, subscription level) is different than a "customer" in "delivery" bounded context (address, phone, etc)

[VahidCheshmy]

According to Eric Evans' book Domain-Driven Design, a bounded context is considered part of the strategic patterns, rather than the tactical ones.
- Tactical patterns include things like Entities, Value Objects, Aggregates, Repositories, etc.
- Strategic patterns are more about how different parts of the system relate — like Bounded Contexts, Context Maps, and Ubiquitous Language and etc.

[AbiyGirma-ke]

Arguably one of the most straightforward and effective explanations for DDD. I appreciate the excellent content.

[eng_channel-kzzs]

This is the best DDD video I’ve ever seen
Thank you!!

[adegoodyer]

Great summary and explanation - one of the best videos out there. Many thanks!

[xSerg]

Thank you for the video. I think, I have to watch it once more time

[bmhlgkl]

Thanks for your video! Interesting to see that you place controllers inside of the application layer. From my experience controllers are often placed inside of the presentation layer. Controllers are responsible for handling incoming requests, orchestrating responses, and interacting with use cases or application services. These responsibilities are specific to how the application interacts with the outside world (e.g., HTTP, WebSocket, or any other interface). The application layer, on the other hand, focuses on the core business logic and rules, independent of delivery mechanisms like HTTP or UI.

By placing controllers in the presentation layer:

- You isolate delivery-specific concerns (e.g., web or API handling) from the core application logic.
- Changes to the delivery mechanism (e.g., migrating from REST to GraphQL) don’t impact the application layer.

The application layer should define use cases or services that can be reused across multiple interfaces (e.g., CLI, API, scheduled jobs).

What's your opinion about this? Thanks

[casiezeq]

I love free education, thank you so much!

[patrickonielbernardo]

excellent explanation for DDD. thank you for sharing this.

[erickgeneric]

You are a great teacher. Excellent stuff ❤

[AbhilashKumar-km]

At 2:20 you mentioned that we're only going to talk about the problem in strategic design problem space, and not the solution. Then you explained the "value" component of the problem space as the general solution our app is going to provide.
Can you explain this part please?

[yakoublarbi]

Thank you so much for this video, one of the best

[Shuyinz]

This is gold! Thank you for sharing this video!

[LinkingWorlds]

Controllers folder should not be part of Application folder. Controllers folder is UI - like layer, Application is not ! Application is about Use Cases.

[marcomedrano]

I liked it!! thank you! could you push the complete code on github? I got it and only has the domain folder is available.

[rafigeniuscs]

Great video! What tool did you use to create the event storming diagram? It looks really clean and effective.