How to model this behaviour on multiple aggregates?
2016-06-21 09:05:54 GMT
We currently have a model where a single aggregate models a Person (identification, address, etc) and his/her personal relationships (marriage, partnership, divorces, etc.). This aggregate is fairly large and not all use cases interested in the relations where operating on the Person aggregate, we are looking at the consequences of splitting this in two aggregates (Person and PersonRelation for instance).
As a consequence, there is no possibility to implement something like Person.marriesTo(Person.Id anotherPerson). The reason is the constraint that this is only allowed as long as this relation is not already present at the given moment (A Person cannot be married twice at the same time). This is just an example but there a number of constraints on the model with respect to a Person and his relationships.
We have identified the following options on how to implement this but are not satisfied with any of them:
* Create a domain service. This feels unnatural as the behaviour is not part of the Person that is marrying.
* Implement the behaviour on Person and provide a list of current relationships, e.g. Person.marriesTo(PersonId anotherPerson, List<Relation> currentRelations). This enables the Person to implement the required behaviour, but also requires some state (a set of aggregates) to be injected.
* Leave the orchestration to the use case implementing the behaviour. This also seems wrong, as the domain should be responsible for maintaining its integrity. A use case creating duplicate relationships cannot be prevented by the domain when using this option.
* Inject the Relation repository into Person, so existing Relation instances can be requested as part of the implementation. As I understood, this is bad practice as well.
As this seems a rather general problem, I am curious on how you guys would model this.