Domain Modeling Gone Wrong - Part 2
Вставка
- Опубліковано 23 сер 2023
- So you are applying domain driven design and want to define aggregates. Welcome back to my channel. I'm Derek Comartin from CodeOpinion.com, and I'm going to go over ways to define them with an example domain, and you might be surprised by the outcome. Domain modeling is about capturing domain concepts not just as data and relationships but as exposing behaviors.
🔗 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
Part 1
• Domain Modeling Gone W...
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo...
#softwarearchitecture #softwaredesign #domaindrivendesign - Наука та технологія
"One model doesn't rule them all".
The world will be a better place when more people realize it. 🙈
Agree. One model doesn't need to solve all problems.
That is the essence of DDD, in my view. You have nailed it. All other quality resources out there put the domain & the behaviour in the centre as well. Kudos for pointing out what should be the proper direction.
I'm seeing a better design but I'm not sure that I learned the approach myself. I'm still lost on how to apply this thinking to other domains.
A useful tool to achieve this is Event Storming. After a event storming session who with the domain experts you will be able to see the behaviors and start seeing the different domains.
We've known for 50 years that hierarchical organisation of data is often not a good model of reality. That is why relational databases have been so successful and will continue to be for the foreseeable future. Relational modelling provides a mechanism to represent "the world" (in the form of "true statements about the domain you are interested in") in a logically consistent way.
Aggregates are so often a mistake because the represent a return to hierarchical thinking, which we *already know is usually wrong*. Sure, some things are legitimately hierarchical - and are, ironically, often not modelled appropriately when converted to relational modelling , not because they can't be, but because it seems like knowing how to do it correctly is not common knowledge.
The weird thing is that "thinking in terms of data structures" (often relational data structures) somehow, perversely, leads to inappropriate aggregation. In a relational database we might have orders with a foreign key to customers. But in the relational world you would not say "the orders are a child of the customer data structure". No. Orders are placed by customers, but they are distinct concepts in the model. The mistake becomes obvious when you consider that an order could have many foreign keys. For example, if the order is actually keyed in by someone at a call centre, you might have a "user who created the order". That's a foreign key. Clearly it can't be the case that the order belongs to the customer data structure AND belongs to the user data structure. It can't have "two owners".
The answer, of course, is that "belongs to" isn't the right way to think about it. As you said in this and the previous video, the relationship represents a behavioural connection. The customer *placed* the order. The user *entered* the order.
Very interested to see the video you mentioned about write models vs read models.
I don't have that much experience with using DDD as a modeling approach but I have realized its fallbacks when it comes to aggregates. At least how it is usually implemented. And aggregate is not necessarily something that itself is persisted in a database. As you pointed out. You may also have two entities essentially representing the same thing but in different contexts and with different behavior. That goes for all kinds of objects. I think that the "one consistent model" approach doesn't work.
So no shame if you have two aggregates. An aggregate is not necessarily an entity anyway - it is a consistency boundary.
Hi Derek! Thanks for the great video. The approach to designing aggregates you’re showing looks like a simplified version of an event storming. What’s your experience with event storming in real projects? Also, I agree with another commenter here that an example of how to design a model for a complex domain would help understand the process even better. Please consider making a video on this topic, even a long one - DDD is not something that can be fit into 10 minutes anyway.
Ya. I'd have to make a much longer video, which isn't a bad idea.
At some point I will fully grok it. I swear!
Can you make the example more complicated? 😅
I could, the problem is it would take using a real domain and explaining how it actually works. That doesn't take 10 minutes unfortunately.
@@CodeOpinion Do you have some courses already or any plan for it? That would be awesome.
@@CodeOpinion that is a course I would not mind paying for. $$$
Thanks. Great Video. What would happen if a menu item is removed? will it go reduce the bill? will the guest be notified? Interesting to see these behaviors shaping up the model.
I wouldn't suspect so as the price was at the time of the dinner party. You'd likely be recording prices as of that time rather than referencing them.
Hey Derek, I am using Result monad in one of a DDD and CA project. I have an abstract Error class for DomainErrors. And the system must support different cultures. What I do is carry errors to the upper layer and there is a ResultHandler transient service which basically does error translation with IStringLocalizer based on a dictionary contains all possible DomainErrors and translated mesages. But I find it overwhelming. How do you use IStringLocalizer or another culture support tool?
I can only speak from my experience, but what we do is immediately translate/localize any "Business" or "Field Validation" error's message at the place where they're defined.
E.g. we pass the translation service into our fluent validation validators that does the translation right then and there using the "WithMessage" functionality and we pass a the translation service to our command/query handlers that might need to return a localized business error.
There's 2 ways to go about localization:
- either you store everything in code, which means you need to recompile your app whenever a translation needs to change (not recommended)
- or you store translations externally (in files, external translation services, in a table in the database,...), which means you can update translations on-the-fly.
For both ways, I'd recommend using an in-memory cache to translate keys to localized strings as fast as possible.
Note:
In our use-cases, we haven't needed to react to any specific business or field validation error, so we just have a concrete class for Business Errors (just has a localized message) and one for Field Validation Errors (has a list of (path + localized message)).
So with CQRS, if we are using a DDD approach, would the Read and Write workflows be considered Read and Write aggregates?
I prefer to see aggregates for write-model only. In read-model you just select, project, and accumulate data.
Can DDD be used to avoid 'Services' ? In our code we have a 'Service' class for everything, which contain all the behaviour, and thin entities with no behaviour. Really want to learn more about this stuff as it seems cleaner and more OOP-like
There will be some part of the application which will not fall into domains and should not fall into the domain. In such cases you will be needing services. How are you planning on doing db calls and persist the domain objects in the db? You will need service class for that.
@@aakashpoojary3968 put those in command handler not in service
Some of the worst systems I have ever seen in my career were based around Aggregates and designs where the Object/Class/Entity was the boundary of the service or feature. Just a terrible idea. The business process/behavior IS the boundary you want, not the data (or groups of data). OOP has a lot to answer for in this area historically - or at least developers' interpretations of it does.
underrated comment, DDD for me is fluff around a 3 or n layer architecture, and a checkbox at an interview. I would challenge someone who is doing DDD like fanatic to tell me how long it will take change and I mean change the code not build from ground up in order to introduce a new behavior, as in above example instead of dinner let's make it a cocktail drink, instead of reservation let's make a ticketing access, instead of a restaurant let's make it food on the go, or why not an open buffet, or (rarely this happens) instead of supply and demand process with time it a broker process (I order food you make it for me gets changed into I bring you ingredients you prepare me food and what ingredients are left covers the costs or parts of it). I know the answer, is even more that what was spent in order to build the original process, why? because of coupling and object centrist structure, and because it not just building something new, it's mandatory to make sure what exists is not affected. Side note when you have more than 5 years development projects (maybe products is a better term) and are not zombie projects you learn from your mistakes.
Unfair to blame OOP, it predates microservices by decades.
9:46 Have you already published the video?
I haven't gotten to it yet, but I have another video that alludes to this more: ua-cam.com/video/01lygxvbao4/v-deo.html
Thanks
Thanks for the support. Much appreciated
Well, you're right. But in fact, this problem can be obviously seen very early when the design comes up or during the code review. This is very fundamental. Honestly and personally, this is just content making. It's not valuable ultimately. Of course, it's "CodeOpinion", you're own to make it. But as an seniority audience, I have to comment this like putting some personal review after leaving a restaurant. 😇
If this were fundamental and obvious, CRUD wouldn't be the majority of software being written. If this were fundamental you'd see more of this "content" and less of CRUD driven tutorials or tutorials that are tech/solution focused rather than explaining why.
As an intermediate engineer, this is not obvious to me and definitely isn't obvious to the architects and senior developers at my company who continue to design tightly coupled data driven CRUD systems 🥹
No, not really 😄
These type of videos just seem a bit lame, critiquing someone for try to teach others how to implement DDD which is a hard topic. Amichai is not trying to build the perfect production system, he is not going to make a video about DDD and not use DDD but all other patterns is he…
Your critiquing my video as lame. Which is fine. DDD is indeed a hard topic and has, I believe, been overly exposed via all the tactical patterns. There a means to an end. My point was modeling is about understanding and capturing concepts and workflow. Implementation (using aggregates/entities/vo) of those behaviors will reveal the data. Not the other way around. Otherwise you land over complex full of indirection CRUD that's driven by a database schema with no understanding of the actual concepts of the domain. I stand by the video even if you think it's lame.
@@CodeOpinion just for clarity, its not that i think this or the other video as standalone videos are lame, its more the direction of travel of seemingly nit picking on others videos, thats just my feedback. IMO what would be better and i think Amichai suggested it already would be you two collaborating on some content, that IMO would be a win win for the community that like to watch both your videos on such a complex topic as DDD.
I do think that's a good idea. And to be clear on my end I'm using the example domain but this isn't a nitpick on a specific video of any specific person. It's a rebuttal to the primary way these concepts are explained. I do think us collaborating on a video is a good idea.
@stevehiggin He has a course now about DDD and it's not cheap. Just FYI :) Derek just shows the correct way of applying DDD. Otherwise, majority of the community will probabily learn it wrong.
@stevehiggin Dude, you're completely missing the point!!! Derek is NOT criticizing Amichai's courses (or anyone else work). The extreme large majority of courses out there are to TEACH you how to build stuff, they're not extremely advanced, because that would be too long and too complicated! It would require a separate course, for a difference audience. I'm very thankful to Derek @CodeOpinion for sharing bits of information to all of us. Derek, PLEASE do not stop with your videos like this one, I'm sure there's lots of us who learn a lot! 👍🙏 THANK YOU for your work.