Do you need Domain Driven Design?

I often read comments about how Domain Driven Design is too complicated or overkill. Then there are others new to DDD that want to apply it, especially the technical patterns, everywhere. So the question is, should you use Domain Driven Design? The answer is somewhere in the middle. Let me explain.

🔗 EventStoreDB

💥 Join this channel to get access to source code & demos!

🔥 Don't have the JOIN button? Support me on Patreon!

0:00 Intro
0:41 Context
2:16 Microservices
4:07 Logical Boundaries
7:05 Capabilities

#domaindrivendesign #softwarearchitecture #softwaredesign

[ryanvdk]

That "Update Address" example is a really good one. I find myself asking that more often when someone tells me they need a CRUD screen. "Ok, but why would you update this field?". It can give some insight into the behaviors associated with the model as well.

[TricoliciSerghei]

Oh man, your channel is a gem for me.. DDD is something I'm trying to wrap my head around for a while now.

[andrewallbright]

I… I learned about DDD in “Unit Testing: Principles, Patterns and Practices.” I will admit that I got really excited and thought it was a silver bullet for everything. I bought more books, discovered this channel (which is great!), and spent time thinking about DDD. I tried to apply my naive implementations everywhere. This is not how one ought to approach engineering, ideally.

Now I view a software project as a set of (ever changing) requirements. Simplistically, the requirements generate a complexity budget. That complexity budget must be considered when applying patterns. Don’t make a super complex thing when a simple thing will do.

I will probably return to DDD as my quasi ‘first principles’ complexity approach seems to be leading me back. Maybe!

Okay, haha time to watch the video. I’m probably way off topic.

[swiftybathero]

I would also mention that we can distinguish two parts of DDD - strategic design, which describes boundaries (bounded contexts), and tactical design - which describes building blocks, implementation details.
If we have a system, where we define boundaries well, but each of them contains only CRUD elements - is it DDD? As time goes by and I gain the experience - I would say - yes.

I think that the biggest problem nowadays is that companies are going all-in when deciding to "do DDD". They threat all boundaries equal in terms of non-functional requirements, while very often is an overkill for simple cases.

As we speak about "Update Address" - do you have to necessarily seek a "specific business meaning" in order to model it as a process/behavior of your aggregate? I don't think so. IMO (but this is my subjective opinion) there always can be some cases, where part of your aggregate will have small CRUD-y elements.

[FlaviusAspra]

There is a simple practice which Eric Evans also recommends:

Make a hexagonal monolith, clean architecture with an isolated domain model, which has use cases as boundary.

Then introducing DDD can (and should, according to Evans) be done gradually, use case by use case.

[marna_li]

To someone like me who has previously been working without the insight and the management insisting on treating everything in multiple domains as one, one database - DDD is golden.

[kimstacks]

looking forward to the event modeling, event storming, and value stream mapping when they come out. Well done 👍

[xxtvccy]

I believe even in the simplest of domains, DDD is useful. The core concepts are still valid and will help, and then you can add the extra bits later if you need it. But ubiquitous language is useful no matter how small the solution is. Which is why I can't even see a place where DDD isn't useful when building software.

[mdway]

Such a great honour having my comment quoted... ;)

[vinylwarmth]

Great video as always. Thanks for helping me think more clearly about system boundaries and to highlight this can easily be achieved without "microservices"!

Looking forward to follow up videos 👍

[iliyan-kulishev]

I have a monolith project (aspnet core blazor) that is organized along the lines of CQRS and Vertical Slices. So far it has been very CRUD in nature. But now I'm getting into a module that on the surface looks like a case for aggregate (in DDD lingo).

Do we really need aggregates and domain layer at all with cqrs and vertical slices? The validations you would do in an aggregate you can do in CQRS style handlers for the same tasks (fx AddItemToBasket, RemoveItemFromBasket).
Am I wrong? What am I missing?

[devagr]

90% of Derek's videos can be boiled down to "BOUNDARIES"

[DominicBurford]

A great video that gets to the heart of when, where and why you might apply DDD principles. You have a new subscriber.

[TristanOnGoogle]

You are using the word "boundary" in place of "bounded context", right ?

[balajichesetti]

I believe DDD would be a great fit for the Ordering & Delivering bounded context due to its complex business rules. Am i right here?

[derrick]

Great video. I had a question. Let's say I have 3 bounded contexts (Order Service, Payment Service, and Fulfillment Service). The Order Service has a state machine (or Orchestration design) and it talks directly to the UI. The Order Service communicates to the Payment Service and Fulfillment Service via asynchronous messaging. The scenario is that let's say the UI sends Credit Card information to the Order Service for validation (i.e., to check if the Credit Card length is valid). The question it okay for the Order Service to handle the Credit Card validation since it a validating Credit Card length or should it respect the Bounded Context by delegating the Credit Card validation to the Payment Service?

[mabdullahsari]

That's the longest "CQRS" I've heard by far haha. Thanks for the video.

What are your recommendations for getting started. I was thinking about getting “the blue book” but heard that it was kinda outdated and complex. Any thought?

[sathyajithps]

Great video. Nice example for context of the software.

[MrAyuub]

Hey mate, thanks for the content its been invaluable. What books would you recommend to start properly learning about domain driven design