CODEWITHSUNDEEP
phpdoctrine-ormdoctrinedomain-driven-design
Quentin Pautrat
Quentin Pautrat

Reputation: 3

ManyToOne relation with Doctrine against Domain Driven Design

I'm facing to an issue with Doctrine relation and DDD.

I already searched a lot but I didn't find a suitable answer.

Let's take a simple example:

I have an aggregate Category and an aggregate Product. I would like to have a ManyToOne relation between Product and Category.

Unfortunately Doctrine makes me add an attribute $category in my Product. But as Vaughn Vernon said, aggregate should reference to other aggregate by his identity, not by the aggregate itself.

Moreover even if I do this, Doctrine overwrites category_id to null if I don't set $category.

My only solution, at this moment, it's to add category_id field in mapping definition and add foreign key by myself.

Is there any other solution ?

Upvotes: 0

Views: 494

Answers (2)

DrSchimke
DrSchimke

Reputation: 96

I just would add a property categoryId to Product and that's it.

So I can't navigate from Product to Category directly, but instead I would need the CategoryRepository to fetch the respective category object, if I need it.

I lose the lazy loading convenience, but the aggregates are separated clean and nice.

Upvotes: 0

Cerad
Cerad

Reputation: 48883

I suspect you maybe trying to use the wrong tool for the job. Doctrine 2 is an Object Relational Manager hence it focuses on objects. If you read through the docs you won't find very much on domain driven design.

Given that Doctrine focuses on objects then:

$category = $product->getCategory();

Makes perfect sense. It also maps nicely onto how sql is designed to work.

If you really want a property Product::CategoryId then go ahead and add it. The latest Doctrine even has limited support for value objects.

But if you then want to somehow access the actual category object then you will need to add in your own query somehow. Kind of makes the orm code pretty much useless as you would be handing your own relations. Maybe drop down to pdo or the database access layer.

I have seen a few articles trying to do what you want but they barely manage the simplest cases and are impractical for any kind of production scenarios. Especially since DDD implies complex business logic.

Upvotes: 1

Related Questions