DDD is just giving a $h!t about your Domain
Вставка
- Опубліковано 19 лип 2023
- When illustrating Domain Driven Design (DDD), sample/reference applications do more harm than good. Overall in a vacuum, they're a net negative. It isn't easy to convey the complexity and trade-offs made using trivial code examples. Beyond that, the code samples themselves are the wrong starting point.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via UA-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo...
DDD Crew
github.com/ddd-crew/ddd-start...
#domaindrivendesign #softwaredesign #softwarearchitecture - Наука та технологія
Sample application stack: .NET, serverless, event sourcing with CQRS, microservices architecture, integrated CI/CD pipeline, edge node globally hosted UI with Blazor WASM authenticated with Azure AD and styled with MudBlazor.
The application & business domain: TodoList containing TodoItem, which has Name and IsChecked properties. Full feature list: Add/Update/Delete items
In defense... If implemented correctly, it would propably scale to the moon 😂
Exactly.
@@flobuilds Yes, you must be prepared when the business folks require changing the database engine. AGAIN.
@@Greenthum6 maybe a change to cassandra or scylladb ☠️
The issue with these examples is it’s virtually impossible to learn WHY things are dove a certain way in DDD without going through the issues they solve yourself. I tried to refactor our systems code base to a DDD vertical slice architecture, I made some good decisions, but their were times I was just lost. I didn’t know what the “proper” technique to use was. Eventually I settled in a middle ground between things that suited our needs and stayed in line with things I’d been reading up on. As we’ve added new features and learnt more about our system, the questions I didn’t have an answer to “why do it this way, why is so and so bad” become obvious. There is no way to genuinely learn this stuff without trying, failing, improving and trying again. Currently our system is screaming out for a event driven architecture approach, I was oblivious to this when we first planned it (wasn’t me actually was a dev who has since left) but now I’m find myself thinking “that solution would be so much more efficient and elegant with an event based system”. I’m sure I’ll fail, learn and improve plenty on this endeavour too
I watched this a while back or maybe I didn't and I'm thinking of one of your other videos, but I laughed out loud because I thought of all the "Building a TODO List: an introduction to domain driven development" tutorials I've seen out there. You hit the nail on the head when you said that sample projects do more harm than good.
No kidding! I was just thinking about the many todo list repos I've seen that are so insanely complex for NO reason but to show the pattern. It's such an awful way to learn patterns.
Agreed but I find that most developers want to choose a pattern and apply it everywhere regardless of complexity or use case for consistency. So if one model has extreme complexity but another doesnt, generally I see the implementation is done as both being domain models or none. most devs wouldnt have 1 domain and 1 script. Whats your opinion on that?
Ya, very much agree that's pretty common. I understand why because of varying degrees of experience and skill and often reasons why that happens. Force people down a road to conform to the "here's the way we do it" so there's going offside incorrectly. I get it. However, you can be making things more difficult in the long run because of it. Hence why I get comments about "I have to change 5 layers to make a single change" when something is purely CRUD.
There are also degrees to patterns. For example you can use Value Objects and Entities but not Aggregates because maybe you prefer Transaction Scripts in maybe something like a service or right in your MVC API controller. That is not real DDD but some DDD patterns are hard not to see the urge to apply almost everywhere, especially in classic enterprise apps.
I like this explanation about the samples being too simplistic to properly demonstrate the concept that needs to be learned.
love your topics.
AND i appreciate the simple thumbnails.
The maddening thing about toy examples is it's not hard to to think up domain complexity.
Also, people writing an example could pick a domain they have some knowledge about and not handwave all the complexity away. I worked on a project a while back that was really good for this: it was a pretty small domain but the interactions were complex. So when I test things out I like to use that domain as a test bed of sorts.
I can't even express how much I agree with you Derek. Perfectly put!
oh and btw, that repo you looked at belongs to a coworker of mine. I am currently actively teasing him in our teams channel xD
It's not a bad thing as an author to go through those motions, but as an outsider with no context, just looking at the code, it can be for the reasons I outlined.
A non-trivial part of my work is teaching, which is to say that I write "worthless" reference applications for a living. And I can't agree more. There is no suitable example, reference, or canonical domain model that is separate from the aggregated learning of the team that discovered/built it over the life of the application. Write tests, deliver stuff frequently, iterate. You will end up with your own special unique snowflake.
07:33 When you think your microphone has an issue and you replay that part two times, just so you can realize that Derek was farting on you 🤣🤣🤣
Figured it was a nice touch to add a fart.
I think the biggest problem lies in terminology, it would have been better named Business Driven Design. You have to talk with and listen to business people and find out together, as you briefly mentioned, what processes drive the business and model those properly using the best DSL for each. IT is too stuck on patterns and best practices for its own good. It is called computer science, but I often experience it as computer religion. In my opinion, it should keep itself as far away from dogmatic practices as possible and has failed miserably at that the past decade. Sample code bases and preaching patterns are some of the root causes of that failure.
Great videos, keep it up, you have a great way to explain difficult stuff in an easy to understand way, rare skill in our Industry.
Really good video. I totally agree. Now I would love to see someone attempt to teach the transition from transaction script to domain objects. I imagine it would take the length of a course instead of a single video to show, but finding the pieces that are shared between transaction scripts and making decisions about how to extract them into rich objects would be fantastic.
I've done something similar before but probably worth another video. Thanks for the suggestion
@@CodeOpinion
Would be really happy if you choose any different system than Products, Orders or Warehouse. A totally different domain.
Hi! I really like your videos and I would love it if you could recommend me other channels that teach software design/architecture
Ok,so in order to have a good grasp about a domain we are addicted on business expoert,Are not we?,we can do without their help.
And seconddly ,for the verry begining when we don't have any deep knowledges about the doain ,is it ok to start with the simplest Transaction script?!thank you!
Derek, one of the things I believe many are struggling with, is getting a mental model of what application/domain/team is responsible for what event, and how these should interact. One way to get to that point is to collaborate, visualize and discuss. That's actually one of the things that tends to draw me to Event Modeling, are you familiar with this? Is there any other tooling that is your go-to for this kind of thing? I'm not yet familiar with EventStorming, but I keep hearing about it, so maybe it's better?
The few times I've been able to do such an eventmodeling session, lots of input and discussion seem to come naturally to people, I really like that aspect.
I am familiar with Event Modeling. Event Storming is similar but different. Event Storming is more for collaborating for discovery, exploring the domain. Event Modeling is more about output for building the system.
@CodeOpinion I like that you highlight that the key is to put the focus on understanding the domain before coding, but you also said that is not possible to explain concepts with a complex sample. I would love to see how would you explain DDD concepts, and not just saying when not to do it (just bc I saw you criticize the work of others a few times 😉)
Thanks for the comment. How would I explain DDD concepts? Well not in a 10 minute video 😂. But in aggregate you probably can get the gist from a pile of videos I've published. The tactical patterns are a means to an end and aren't required at all. For example, in a functional lang you aren't creating object models as domain models. If I were spending time explaining it, in length, it would be more in depth to each parts of the last diagram I showed and how the iterations are important.
@@CodeOpinion and after I commented I saw this video of yours which I think it's really great (ua-cam.com/video/PrJIMTZsbDw/v-deo.html) that you published before becoming a reference-app killer 😋. Just kiding, only wanted to say that ref apps are not bad if we are aware they are over simplified demostrations of how to estructure the code, that we can apply it when we have a complex domain.
Almost in every video you mention transaction script, could someone explain me what it actually is. I was doing DDD, I was thinking so, but in most cases it's just a wrapper above setter.
An example of the transaction script is when you inject DbContext, do some business stuff in the method, in the same method you update DB and at the end you call _db.SaveChanges(). There is no domain objects, you usually work with your DB entities directly, update the state, and save them into the DB.
@@m4r10x2 thanks a lot!
The code should be an asset at the end of the understanding of the problem to solve. When you start from the code you missed all about DDD. And TRY HARD to have a common language between all the people involved in solving that problem, that language should be on each line of code. The code will change, be ready for that, because the domain model (the problem) will change iteration after iteration.
But what open source projects that are not samples as good study points? Do you have any such examples :)
That's the problem. There aren't any that I'm aware of.
@@CodeOpinion Worth a shot ;).
I would bet all really good examples are highly protected corporate secrets because they probably generate a lot of money. No way anything truly good would be just freely available. Good stuff costs money.
Completely agree
I think model is overcomplicated. It should be done either with validator, or validation attributes.
"... You should start caring." Right into ad read, lol. No disrespect just thought it was funny.
Yepp, DDD is not a coding pattern!
Finally someone said it!! Completely agree, and that is one of the main reasons of bad DDD coding examples out there, and DDD being really misunderstood... and abused. DDD is not a coding pattern, neither an architecture!! It's a guide to model a business... my God!!
Reference projects are built by technical people who care about the implementation details before the process of understanding what they are building. I think we are all guilty of doing this at some point.
I have tried to make a reference project that shows the details, but you always end up with some simple scenario that doesn't illustrate more than the concepts in code. Concepts that are hard to grasp without the context.
And they are misleading people who are looking for samples on how to implement code "DDD"-style. Not even telling them about the tradeoffs that they have to make.
Not every developer is as passionate about programming and learning new things. Seeing everything from a technical lens is not gonna sell if you are in a team. There are people who just want to do their jobs.
Yup. Why I included "in a vacuum" they are a net negative because as you mentioned they don't illustrate trade-offs or often the "why" something is being done because the examples are so trivial. They have to be trivial to get the gist across because nobody wants to spend days to grok some all the domain complexity.
I think they are mostly to get you a structure to get started with, but not a full prescription on how things need to be done. My opinion is that it's more about getting the boilerplate part done with something that might more closely ressemble what you're trying to achieve rather than them being a fully closed prescription on how things need to be done.
This may be the best title for a video that you've ever created!
😂 I agree
Most of the samples are not helping at all, because when we really to use these, it's in a much bigger scale and in a more complex scenario.
S.A.M.P.L.E - Simple And Mediocre Problem Learning Exercise
;)