Reflexion note about: DDD and Aggregate implementation with Symfony and Doctrine
Etshy
Posted on June 27, 2023
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 DataModel
s are completely separated from the Aggregate
s and you can easily make different Aggregate
s 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 Comment
s, 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.
Posted on June 27, 2023
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.
Related
June 27, 2023