Reputation: 93
In my domain, i have an AggregateRoot named User and a child entity named Register_Cedro_Services.
The child entity is updated from a SAGAS Orchestrator, who manage the register of our user in a third company. This entity has data returned from that third company.
If set my root to reference the child entity and one day my organization leaves the another one, i'll have to change my code and User table. In this case, i would not be braking the open/closed principle?
So, if i set my child entity to reference the root, i wouldn't have this problem.
Upvotes: 0
Views: 202
Reputation: 56
If I understood correctly: you have a User aggregate which by the looks of it has a command (because its a verb) called "Register_Cedro_Services" which will then add some sort of child record to the User aggregate. This will be triggered by a saga.
However, you have modelled this in a way where the aggregate will hold the reference key to the child entity. This is very unusual and I would not recommend this. The child entity should have the reference key of the aggregate.
Also, it appears you are concerned that the data stored in the child entity contains data supplied by a third party? If you have used your anti-corruption layer then there should be no issue.
Lastly, I have the impression you are trying to future proof your solution. Is this really a requirement? In software engineering future-proofing is highly correlated with over-engineering and is seen as a bad practice.
Upvotes: 2