This Is How Domain-Driven Design Makes Object-Oriented Design More Powerful

[@stjepankarin]

This is probably the best video summarizing all important aspects of DDD and its relation to OOP, CQRS and (eventual) consistency. Balancing all of these is hard, unique to every application and use case, as there are pros and cons in which ever path you choose, and this video also mentions few words on that as well. Thanks for this awesome content!⭐

[@zoran-horvat]

Thanks!

[@azir8930]

You opened my eyes. Now I see how beautifully it all comes together. Thank you!

[@ShahidMogul]

Love Zoran's unique style of story telling.

[@tuckertcs]

Amazing videos! Would love to see a full course on a REST API or something showing a full example of how to combine DDD, CQRS, Clean Architecture, EF Core, and other topics you frequently discuss.

[@viktorasmickunas2527]

Very, very useful and interesting video and at just the right amount level of detail. Captures the gist of DDD perfectly! Thank you.

[@EvanMildenberger]

What a time to be alive!

[@F2H16]

Amazing! You are an articulate person, it would be nice to get a DDD course (An affordable one) from you. It would have covered your programming mastery and eloquence to deliver the goods.

[@jeancarlosreyesencarnacion]

This was good, can you continue with this explanation about DDD and become this to a serie? ❤🎉

[@zoran-horvat]

I plan to add more videos on DDD from time to time.

[@majormartintibor]

Masterpiece of a video!

[@rorycawley]

Truely masterful work, thank you

[@benqbenq]

3:08 when you see it

[@PieJee1]

I'd love to hear your opinion if MVC complicates DDD if used together. To me the reason anemic domain objects exist is because MVC is in the DNA of a a web developer and if you would apply the DDD concepts the problem is keeping the ubiquitous language in the domain objects. I loved for example the concept of the Symfony API Platform when it was released where you just define entities and let it create the API yourself, but now a few years later I do not like the path it took; it is unusable if you don't build everything as anemic domain objects. I'm now working on my own implementation of naked and restful objects and even though it's still in early developments, many DDD concepts fit much nicer!

[@WayneGreen-g8l]

DDD doesn't define the concept of a "transaction" very well which makes the rule of "one transaction operating on one aggregate" confusing. For example, if one aggregate does an operation on a database and then that aggregate calls the root of another aggregate which then also does an operation on a database, is that one or two transactions? Or also, if some service (say for example in the application layer or in the domain layer - it doesn't matter) calls a repository in the unit of work and then based on the result later calls a different repository in a different persistence layer which operates on a different aggregate, did we just witness one transaction operating on two aggregates (thus breaking the rule) or did we have an acceptable one transaction per aggregate situation because one repository call operated on one aggregate (as the first transaction) and the other repository call operated on a second aggregate (as the second transaction)? I once had a manager who believed that any front-end app call to a Web API endpoint qualified as one transaction, and so therefore you were only allowed to make one atomic unit of work per controller endpoint. The debate became heated and . . . let's just say I don't work there anymore, LOL. But the DDD concept of a transaction is usually not well explained in the sources I've studied so far. I hope there is somewhere that explains these rules more clearly.

[@zoran-horvat]

DDD defines that the single instance of a single aggregate is updated atomically. That definition is aligned with what most document databases promise, i.e. they guarantee writing a single document atomically and usually nothing more.

[@ThugLifeModafocah]

This was a good one. Thank you.

[@abj136]

I learned a long time ago about OO Design, but Entity, Service, Bounded Context, CQRS are outside my parlance.

[@zoran-horvat]

Those are very useful in complex systems design. I warmly suggest you read the DDD book by Eric Evans.

[@WayneGreen-g8l]

Eric Evans' book is great, but everywhere I've worked treat developers like code-zombies who are not allowed to talk to the stake-holders and the real domain experts whereas Evans' book rightly and correctly says not to treat us like dumb coders. What usually happens in the real world is that the stake-holders give explanations to some business analyst who explains it to a software manager who then gives us instructions which we are supposed to blindly execute. The problem is that the instructions can be interpreted in many ways and often times, asking questions leads to more confusion. What ends up happening is that the BA has one concept of the domain, the project analyst thinks of it differently, the QA has a different interpretation and says there is a defect where the developer saw it as correct, and the manager is angry that the task goes over the sprint time and says it must be because you're a slow developer (ignoring the details of what happened). Then you have to address that defect while working on the next sprint. Eric Evan's DDD (like the agile methodology) has been made rigid, regimented, conquered by upper management who want use it to incorrectly measure progress and velocity, and dogmatic. We're not allowed to talk to the stake holders, we get ambiguous instructions, there's no document clearly explaining the model, there is no reference to a ubiquitous language, etc. No, there's just domain objects, aggregates, etc. that are found only in code. DDD and Agile were great ideas but no one does them correctly and they've been made mechanical like developers are just parts of a code assembly line machinery. @@zoran-horvat

[@zoran-horvat]

@@WayneGreen-g8l I am very well aware of the things you have explained here. The business analyst idea, along with rate releases and feedback organized around bug reports is the old way of doing things, ridden with issues.

[@manya.korolevskaya]

Hi Zoran! Do you use anything except MediatR for domain events publishing/subscribing?

[@zoran-horvat]

Actually, no. MediatR is a good choice.

[@GC-qe8vc]

On this point, you should watch David Comartin's videos on the outbox pattern. We implement it with MassTransit. It is absolutely necessary for Integration Events (i.e. the ones that cross bounded contexts) and... mostly necessary for Domain Events (i.e. within the same bounded context). I say "mostly" because you may have (rare) cases where you don't need guaranteed delivery of a Domain Event, although I would suggest using the outbox pattern by default even within your bounded context.

[@davidpccode]

Wowwwww wowww wowwwwww what the **** you my friend are the best of the best .thank you

[@aanders0n]

Thanks for this one! Will you release a new OOP course on Udemy that is being recorded right now, if so will be any different from the current one?

[@zoran-horvat]

The new course I am working on is the continuation of the Beginning OOP with C#. It will convert the most important design and coding principles when using C# to design a domain model, structures, and algorithms.

[@nickbarton3191]

One way to update, as the aggregate; bolt of lightning just struck me.

[@zoran-horvat]

That was my reaction, too, when I first learned about that idea from the DDD book. My whole life passed before my eyes as I saw innumerable occasions where I had an explosion in the number of ways to materialize models from the database only because there were many ways to mutate them. Now, with the aggregates idea, we sustain a certain drop in performance by always materializing the entire aggregate, even in operations that only affect a small portion of it. But then a dozen carefully crafted sets of methods that used to mutate the state in the database suddenly become only one method! The simplifying effect on code is so dramatic that I never looked back after I learned this technique.

[@franciscorusso8062]

I feel so related with this description. Once I started to use Aggregates, even as you mentions to change a small portion, everything became so clear and smooth

[@pyce.]

What is the best attempt to reduce complexity?

[@zoran-horvat]

That depends on the problem you are solving but also on what you consider important in that problem. There is no single design strategy that solves all problems.

[@_IGORzysko]

Hi Zoran, great video! What in your opinion is the better way of doing: (1) entity create methods defined within entity classes OR (2) entities without any create methods, just with particular constructors. In my opinion there is no much danger with constructors as far as properties of entity class are properly defined, with great awareness - do you notice any red flags here? 🤔

[@zoran-horvat]

That is pretty much the same thing in my opinion. The only meaningful difference is that factory methods are - methods, and as such they are assignable to delegates. You cannot assign a constructor to a delegate because it is not a method.

[@_IGORzysko]

@@zoran-horvat Thanks!