Re: How to model this behaviour on multiple aggregates?

I would recommend that you model a Marriage Contract with the constraint
that you cannot have two "live" contracts involving a given Person, where
a Marriage Contract is live if and only if:

  - it has not been dissolved
  - both participants are alive.

This because "dissolve" is properly an event of Marriage Contract and not
of its participants.

Regards
Ashley

> 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.
>
>
>




------------------------------------
Posted by: [email protected]
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/domaindrivendesign/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/domaindrivendesign/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/