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

preview_player
Показать описание

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 📱👨

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
👨 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 YouTube 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
Рекомендации по теме
Комментарии
Автор

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!⭐

stjepankarin
Автор

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.

tuckertcs
Автор

Love Zoran's unique style of story telling.

ShahidMogul
Автор

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.

FH
Автор

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

viktorasmickunas
Автор

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

davidpccode
Автор

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

abj
Автор

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.

WayneGreen-gl
Автор

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

nickbarton
Автор

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

manya.korolevskaya
Автор

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

azir
Автор

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!

PieJee
Автор

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?

aandersn
Автор

What is the best attempt to reduce complexity?

pyce.
Автор

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? 🤔

_IGORzysko