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

Become a sponsor to access source code ► / zoranhorvat
Join Discord server with topics on C# ► codinghelmet.com/go/discord
Enroll course Beginning Object-Oriented Programming with C# ► codinghelmet.com/go/beginning...
Subscribe ► / @zoran-horvat
It is my most profound belief that only through understanding the problem we are facing can we measure the impact of any given method that pertains to addressing that problem. So it stands for the Domain-Driven Design, which this video will try to assess. What problem are we trying to solve with design, and how does DDD help?
Whether some programmers want to acknowledge it or not, Domain-Driven Design has tremendously impacted how we do Object-Oriented Design nowadays. Programmers without knowledge of DDD will speak of entities, value objects, and even aggregates. They will know how to deal with an entity's identity almost instinctively and will take care to reference only specific entities - did anyone say aggregate roots? That indicates there is truth in DDD.
At the other end of the spectrum, we find hardline proponents of DDD who will tell you straight that applying only the tactical part of it is nothing compared to its true power. As if DDD could make all the troubles go away. It cannot, so my experience tells me.
Where is the truth, then? - you must be asking. I can hardly answer that question, but I know another question that is easier to decipher: How can we decide whether to use DDD and to what extent? Answering this question begins with my most profound belief that only through understanding the problem we are facing can we measure the impact of any given method that pertains to addressing that problem.
What problem does DDD address? - that is at the root of all questions. It's the same as what OOD does, only it does it better! Watch the video and learn how DDD adds magic on top of OOD to make it a more expressive and robust design method.
00:00 Intro
01:44 Dealing with Complexity
05:03 Designing with DDD
11:46 CQRS and Persistence
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ CONNECT WITH ME 📱👨
🌐Become a patron ► / zoranhorvat
🌐Buy me a Coffee ► ko-fi.com/zoranhorvat
🗳 Pluralsight Courses ► codinghelmet.com/go/pluralsight
📸 Udemy Courses ► codinghelmet.com/go/udemy
📸 Join me on Twitter ► / zoranh75
🌐 Read my Articles ► codinghelmet.com/articles
📸 Join me on LinkedIn ► / zoran-horvat
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
👨 About Me 👨
Hi, I’m Zoran, I have more than 20 years of experience as a software developer, architect, team lead, and more. I have been programming in C# since its inception in the early 2000s. Since 2017 I have started publishing professional video courses at Pluralsight and Udemy and by this point, there are over 100 hours of the highest-quality videos you can watch on those platforms. On my KZbin channel, you can find shorter video forms focused on clarifying practical issues in coding, design, and architecture of .NET applications.❤️
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⚡️RIGHT NOTICE:
The Copyright Laws of the United States recognize a “fair use” of copyrighted content. Section 107 of the U.S. Copyright Act states: “Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our youtube channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s), but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above.
#csharp #dotnet #domaindrivendesign

[@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!

[@ShahidMogul]

Love Zoran's unique style of story telling.

[@viktorasmickunas2527]

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

[@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.

[@majormartintibor]

Masterpiece of a video!

[@rorycawley]

Truely masterful work, thank you

[@benqbenq]

3:08 when you see it

[@ThugLifeModafocah]

This was a good one. Thank you.

[@user-nw8oi9vn9y]

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.

[@davidpccode]

Wowwwww wowww wowwwwww what the **** you my friend are the best of the best .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.

[@user-nw8oi9vn9y]

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]

@@user-nw8oi9vn9y 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.

[@_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!

[@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.

[@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.

[@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