This kind of more intermediate/advanced content is dearly missed on youtube! Great explanation and example, albeit simplified does illustrate the issue and possible solution in an eloquent way.. i mean elegant 😂
One thing this also does is put off any database transactions until the end. I've found that if you wrap everything into one database transaction at first, you end up stuffing a bunch of stuff in there without thinking about it, and those things (e.g., network calls, memory allocations for instances, etc.) all incur a cost. This can lead to long running transactions in your database which can lead to all manner of issues. This is an elegant pattern. Thanks!
oh god this is perfect. i'm a django developer and i've suffered these issues a lot. i tried learning DDD but couldn't get anything because i was thinking domain models = orm models. but it all made sense in the first 5 minutes of your video. thank uuuuu
I read about Aggregates from DDD a long time ago, and didn't quite figured out them for Laravel ORM (I think it is mostly a thing for Data Mapper) but this helped me to make it sink properly, thank you, still not quite sure why you have `Ticket` and `OrderTicket` Models, and why you pass a `Ticket` to the `addTicket` method and it creates an `OrderTicket` is `Ticket` kind of a ValueObject or a DTO?
9 หลายเดือนก่อน
A "Ticket" is part of the Event aggregate, an "OrderTicket" is part of the Order aggregate (maybe OrderLine would've been a better name). In a modular context, they'd both have the same name in different contexts. e.g Order\Ticket and Event\Ticket.
You probably won't have a ton of line items, however, what if you're dealing with a domain model that could have a lot of "line items"? If you keep pushing into the array, you'll run out of memory. But this is not a "domain" problem. How to solve this?
9 หลายเดือนก่อน +2
I can’t think of a lot of scenarios where you’d have to save a bunch of stuff together in one go. In these cases I’d probably just queue it afterwards, and leave the aggregate root in a pending state until that is done. Do you have a concrete example?
I don't actually. This is just something I was thinking about. But queueing it up seems a good alternative. Thanks! It would be cool if you shared some complex codebase with us so we could take a look a more complex scenarios.
Great video. Thanks for sharing these thoughts. With things like OrderLines - which actually only exist within the order - what do you think of the approach of denormalizing the data structure and not storing it in a separate database table but as embedded entities? This would possibly solve some "problems" with persistence (and of course bring new challenges^^). Keep up the good work. I really enjoying your content.
9 หลายเดือนก่อน
Hey! Thanks for the comment. I’m not sure what do you mean with “embedded entities” - do you mean storing it alongside the order row? If so, I’m not sure - RDBMS are meant for this and persistence/consistency should not be an issue. I can see that working with good JSON support though (e.g Postgres).
9 หลายเดือนก่อน
Although you’d have very limited querying abilities against line items.
Something just doesnt sit right with me when business-related method is mixed with Eloquent "config" method on a Model. Especially when you have the Order model, you __can__ still call save() and all that. The way I see it, there are 3 methods in the save order "flow": start(), addTicket(), place(). Yet they are defined amidst a dozens of Eloquent specific methods: relationship, accessor and mutators, casts,... On top of the inherited Model methods: saves(), delete(), update(),... If someone would onboard 5 years from now, how would he know that these 3 methods are special and belong in a "flow", and that he should not call save() directly? How would he know to organize additional such methods? If we are talking about Aggregates, we are obviously implementing DDD, or at least DDD-like patterns, which separate business logic from infrastructure implementation. I think it best we dont put Domain Models (which handle business logic) and ActiveRecord models (which is atrongly coupled to db) inside each other
9 หลายเดือนก่อน +3
You’re not wrong; I believe my thinking differs in the sense that I am assuming Eloquent was *already chosen* and it represents a domain model (as it does in most apps) - so it’s more of: we have already chosen Eloquent - given the tradeoffs, what can we do to make our lives easier on the long run within those constraints? You’re right , there’s really nothing stopping you from just calling save(), etc, so it’s mostly a matter of documentation and everyone being on the same page.
This kind of more intermediate/advanced content is dearly missed on youtube! Great explanation and example, albeit simplified does illustrate the issue and possible solution in an eloquent way.. i mean elegant 😂
Thank you my dude 🫶🏻
One thing this also does is put off any database transactions until the end. I've found that if you wrap everything into one database transaction at first, you end up stuffing a bunch of stuff in there without thinking about it, and those things (e.g., network calls, memory allocations for instances, etc.) all incur a cost. This can lead to long running transactions in your database which can lead to all manner of issues. This is an elegant pattern. Thanks!
Love your channel and videos, I am learning something new with every one. And I always think about how this could benefit my code base. Thank you!
Thay’s a very kind message. Thank you so much, you’ve made my day!
Such a great idea, very useful.
Thanks!
How do you handle three levels of nesting
oh god this is perfect. i'm a django developer and i've suffered these issues a lot. i tried learning DDD but couldn't get anything because i was thinking domain models = orm models. but it all made sense in the first 5 minutes of your video. thank uuuuu
Happy to be of help 🫡
I read about Aggregates from DDD a long time ago, and didn't quite figured out them for Laravel ORM (I think it is mostly a thing for Data Mapper) but this helped me to make it sink properly, thank you, still not quite sure why you have `Ticket` and `OrderTicket` Models, and why you pass a `Ticket` to the `addTicket` method and it creates an `OrderTicket` is `Ticket` kind of a ValueObject or a DTO?
A "Ticket" is part of the Event aggregate, an "OrderTicket" is part of the Order aggregate (maybe OrderLine would've been a better name).
In a modular context, they'd both have the same name in different contexts. e.g Order\Ticket and Event\Ticket.
You probably won't have a ton of line items, however, what if you're dealing with a domain model that could have a lot of "line items"? If you keep pushing into the array, you'll run out of memory. But this is not a "domain" problem. How to solve this?
I can’t think of a lot of scenarios where you’d have to save a bunch of stuff together in one go. In these cases I’d probably just queue it afterwards, and leave the aggregate root in a pending state until that is done.
Do you have a concrete example?
I don't actually. This is just something I was thinking about. But queueing it up seems a good alternative. Thanks!
It would be cool if you shared some complex codebase with us so we could take a look a more complex scenarios.
I confess I'm just watching your videos because your voice 🤣
Another great vídeo !
Haha I’ll take that as a compliment :-)
@ hahah
Besides that, I liked the content you have here, it's awesome, concepts and examples are rare to find nowadays
Great video. Thanks for sharing these thoughts.
With things like OrderLines - which actually only exist within the order - what do you think of the approach of denormalizing the data structure and not storing it in a separate database table but as embedded entities? This would possibly solve some "problems" with persistence (and of course bring new challenges^^).
Keep up the good work. I really enjoying your content.
Hey! Thanks for the comment.
I’m not sure what do you mean with “embedded entities” - do you mean storing it alongside the order row?
If so, I’m not sure - RDBMS are meant for this and persistence/consistency should not be an issue. I can see that working with good JSON support though (e.g Postgres).
Although you’d have very limited querying abilities against line items.
Something just doesnt sit right with me when business-related method is mixed with Eloquent "config" method on a Model.
Especially when you have the Order model, you __can__ still call save() and all that.
The way I see it, there are 3 methods in the save order "flow": start(), addTicket(), place(). Yet they are defined amidst a dozens of Eloquent specific methods: relationship, accessor and mutators, casts,... On top of the inherited Model methods: saves(), delete(), update(),...
If someone would onboard 5 years from now, how would he know that these 3 methods are special and belong in a "flow", and that he should not call save() directly? How would he know to organize additional such methods?
If we are talking about Aggregates, we are obviously implementing DDD, or at least DDD-like patterns, which separate business logic from infrastructure implementation. I think it best we dont put Domain Models (which handle business logic) and ActiveRecord models (which is atrongly coupled to db) inside each other
You’re not wrong; I believe my thinking differs in the sense that I am assuming Eloquent was *already chosen* and it represents a domain model (as it does in most apps) - so it’s more of: we have already chosen Eloquent - given the tradeoffs, what can we do to make our lives easier on the long run within those constraints?
You’re right , there’s really nothing stopping you from just calling save(), etc, so it’s mostly a matter of documentation and everyone being on the same page.
$command->customer->id, $order->payment->customer etc violate encapsulation
How would you do it?
Concepts are too advanced for me but great video.
What did you not understand? Maybe we can help!
Just use the data mapper pattern lol, active record is such an anti pattern.