Domain Modeling Gone Wrong - Part 2

🔗 EventStoreDB

💥 Join this channel to get access to a private Discord Server and any source code in my videos.

🔥 Join via Patreon

✔️ Join via YouTube

Part 1

#softwarearchitecture #softwaredesign #domaindrivendesign

[henriquesilveriohs]

"One model doesn't rule them all".
The world will be a better place when more people realize it. 🙈

[FH]

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.

[crazyfox]

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.

[allmhuran]

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.

[dandoescode]

Very interested to see the video you mentioned about write models vs read models.

[marna_li]

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.

[robotrabbit]

At some point I will fully grok it. I swear!

Can you make the example more complicated? 😅

[penaplaster]

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.

[nitinpai]

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.

[baranacikgoz]

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?

[Tony-dprl]

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.

[yonatandaniyel]

So with CQRS, if we are using a DDD approach, would the Read and Write workflows be considered Read and Write aggregates?

[danwilson]

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

[yyegor]

9:46 Have you already published the video?

[danglvh]

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. 😇

[stevehiggin]

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…