Reflexion note about: DDD and Aggregate implementation with Symfony and Doctrine

Etshy — Tue, 27 Jun 2023 23:40:31 +0000

Hey Everyone, that's my first post and that's a quite heavy one (for me at least).

It's been quite a long time I read about how to implement DDD and especially Aggregate within a Symfony and Doctrine project and every implementation I saw until now always feels like there is something missing.

So here's some shower thoughts I had today about this.
Of course this idea is far from conclusive and I feel liek it's REALLY too heavy for a real project. And I make this Post mostly to have some backup, if someone ever find this page.

So to summarise, I saw a lot article about making either an Doctrine Entity/Document as the Aggregate itself, or making an aggregate containing Doctrine entities. And Repositories creating these Aggregates.

That's fine by me, and working mostly with ODM I'll surely take the first approach as my go-to as it's way simpler than what I thought about.

But I feel like having our "DataModel" as or within Aggregate are not good, keeping the Infrastucture and Domain layer too tied up.

My "idea", FINALLY!

With all that as backstory, my "idea" is quite simple...
Making the DataModel (Doctrine entities/Documents) part of the Infrastructure layer, and making Aggregates simple classes that are mapped from Doctrine Entities.

For a Query We'd have a process like this:
Controller > QueryHandler > AggregateRepositoryAbstractionService (didn't think about a name yet) > Repository
The Repository is returning the Doctrine Entity/Document
The AggregateRepositoryAbstractionService is calling the repository and map these Entities/Documents to the chosen Aggregate and return the Aggregate

This way, the DataModels are completely separated from the Aggregates and you can easily make different Aggregates for different context.

Let's take the common example with Post and Comments.
And different contexts : GetPostAndComments, GetPostOnly, GetComment, etc.
You could make multiple Aggregate PostFullAggregate, PostOnlyAggregate, PostCommentAggregate, etc.
I think you get this now, PostFullAggregate (with /posts/1 url) would query the Post and every Comments, PostCommentAggregate (with /posts/1/comments/1 url) would query only a comment of the post etc.

Concerning File structure you could have something like that

├── src
│   ├── Application
│   ├── ├── Query // contains the Query, QueryHandler, etc.
│   ├── ├── RepositoryAbstraction // not sure if this should be here though
│   ├── Domain
│   │   ├── Post
│   │   ├── ├── PostFullAggregate.php
│   │   ├── ├── PostCommentAggregate.php
│   ├── Infrastucture
│   ├── ├── DataModel
│   ├── ├── Mapping
│   ├── ├── Repository

Like I said, It's a bit more heavy to develop than common implementation you could find here and there, because you have both Aggregates and DataModel and an optional RepositoryAbstraction.

Hope someone will find this page and will give me his opinion about this, maybe I'm completely wrong.

ps: This Article is really rough, and I could edit some things.

Forem: Etshy

Reflexion note about: DDD and Aggregate implementation with Symfony and Doctrine

My "idea", FINALLY!