Thinking about Aggregates in Active Record

👨‍💻 Learn Test-Driven Development with Laravel!

👨‍💻 Sign up to my newsletter and receive PHP, JS and Laravel news in a weekly-basis:

🎉 Party up:

Thanks for watching!

[tmanley]

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!

[lassestube]

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 😂

[saralightbourne]

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

[turboclown]

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!

[mariano.pualiu]

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?

[afsdab]

I confess I'm just watching your videos because your voice 🤣

Another great vídeo !

[necrotikS]

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?

[khangle]

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

[lpheller]

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.

[bb-giky]

$command->customer->id, $order->payment->customer etc violate encapsulation

[bled]

Concepts are too advanced for me but great video.

[Competitiveforlolz]

Just use the data mapper pattern lol, active record is such an anti pattern.