Re: How to model this behaviour on multiple aggregates?

"Remy Fannader [email protected] [domaindrivendesign]" <[email protected]> Thu, 23 Jun 2016 05:51:22 +0200
Newsgroups gmane.comp.programming.domain-driven-design
Message-ID <CAMdXxPBdSvnt9XWZxqXcGqsJ1P=+HGrMWR7GYXuetOgXHbN6EQ@mail.gmail.com>
--94eb2c1477d2b3ee730535e9f764
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Putting person and relationship on par is critically misguided because
relationships don't have root identities. Moreover the matrimonial status
is meaningful independently of the identity of the person concerned.
https://caminao.wordpress.com/what-who-how-when-where/when-representations-=
are-to-be-used/synchronization-objects/

On 22 June 2016 at 09:39, R=C3=A9nald VENANT-VALERY [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> Once we had some needs similar to yours.
>
> On the persistence side, we created a "third store" in a relational
> database to be able to consolidate and deduplicate data. We created a
> "roles table" to link all thirds together. An item of this table is
> composed of the following information :
> { RoleId, Third1Id, Third2Id, ValidityStartDate, ValidityEndDate }, with
> light validation rules.
>
> The software repository is giving us a graph of connected thirds,
> expressed in clear business language (Ubiquitous Language) :
> { Client, Address, { Spouse , Employer }}
>
> Complete validation occurs in the Client aggregate root... this allow us
> to manage many different graphs with specific validation rules for each o=
f
> these...
>
> Hope this helps.
> ------------------------------
> De : [email protected] [domaindrivendesign]
> <[email protected]>
> Envoy=C3=A9 : =E2=80=8E21/=E2=80=8E06/=E2=80=8E2016 22:36
> =C3=80 : [email protected]
> Objet : [domaindrivendesign] How to model this behaviour on multiple
> aggregates?
>
>
>
> 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 a=
nd
> not all use cases interested in the relations where operating on the Pers=
on
> 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 wi=
th
> 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<Relatio=
n>
> 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. Thi=
s
> also seems wrong, as the domain should be responsible for maintaining its
> integrity. A use case creating duplicate relationships cannot be prevente=
d
> 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 woul=
d
> model this.
>
>
>=20
>

--94eb2c1477d2b3ee730535e9f764
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





<head>

<style type=3D"text/css">
<!--

/* start of attachment style */
       .ygrp-photo-title{
         clear: both;
         font-size: smaller;
         height: 15px;
         overflow: hidden;
         text-align: center;
         width: 75px;
       }
       div.ygrp-photo{
         background-position: center;
         background-repeat: no-repeat;
         background-color: white;
         border: 1px solid black;
         height: 62px;
         width: 62px;
       }

       div.photo-title=20
         a,
         div.photo-title a:active,
         div.photo-title a:hover,
         div.photo-title a:visited {
           text-decoration: none;=20
       }

       div.attach-table div.attach-row {
         clear: both;
       }

       div.attach-table div.attach-row div {
         float: left;
         /* margin: 2px;*/
       }

       p {
         clear: both;
         padding: 15px 0 3px 0;
	 overflow: hidden;
       }

       div.ygrp-file {
         width: 30px;
         valign: middle;
       }
       div.attach-table div.attach-row div div a {
         text-decoration: none;
       }

       div.attach-table div.attach-row div div span {
         font-weight: normal;
       }

       div.ygrp-file-title {
         font-weight: bold;
       }
 /* end of attachment style */
        -->
        </style>
        </head>
<html>
<head>
<style type=3D"text/css">
<!--
#ygrp-mkp {
  border: 1px solid #d8d8d8;
  font-family: Arial;
  margin: 10px 0;
  padding: 0 10px;
}

#ygrp-mkp hr {
  border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
  color: #628c2a;
  font-size: 85%;
  font-weight: 700;
  line-height: 122%;
  margin: 10px 0;
}

#ygrp-mkp #ads {
  margin-bottom: 10px;
}

#ygrp-mkp .ad {
  padding: 0 0;
}

#ygrp-mkp .ad p {
  margin: 0;
}

#ygrp-mkp .ad a {
  color: #0000ff;
  text-decoration: none;
}
-->
</style>
</head>
<body>



<!-- |**|begin egp html banner|**| -->

<br><br>

<!-- |**|end egp html banner|**| -->


<div dir=3D"ltr"><div class=3D"gmail_default" style=3D""><span style=3D"fon=
t-size:small">Putting person and relationship on par is critically misguide=
d because relationships don&#39;t have root identities. Moreover the matrim=
onial status is meaningful independently of the identity of the person conc=
erned.</span></div><div class=3D"gmail_default" style=3D""><a href=3D"https=
://caminao.wordpress.com/what-who-how-when-where/when-representations-are-t=
o-be-used/synchronization-objects/">https://caminao.wordpress.com/what-who-=
how-when-where/when-representations-are-to-be-used/synchronization-objects/=
</a></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n 22 June 2016 at 09:39, R=C3=A9nald VENANT-VALERY <a href=3D"mailto:corbak=
[email protected]">[email protected]</a> [domaindrivendesign] <span dir=3D"=
ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_b=
lank">[email protected]</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">


<u></u>









=20
<div style=3D"background-color:#fff">
<span>=C2=A0</span>


<div>
  <div>


    <div>
=20=20=20=20=20=20
=20=20=20=20=20=20
      <p>












=20
</p><div><div style=3D"font-family:Calibri,sans-serif;font-size:11pt">Once =
we had some needs similar to yours.<br><br>On the persistence side, we crea=
ted a &quot;third store&quot; in a relational database to be able to consol=
idate and deduplicate data. We created a &quot;roles table&quot; to link al=
l thirds together. An item of this table is composed of the following infor=
mation :<br>{ RoleId, Third1Id, Third2Id, ValidityStartDate, ValidityEndDat=
e }, with light validation rules.<br><br>The software repository is giving =
us a graph of connected thirds, expressed in clear business language (Ubiqu=
itous Language) :<br>{ Client, Address, { Spouse , Employer }}<br><br>Compl=
ete validation occurs in the Client aggregate root... this allow us to mana=
ge many different graphs with specific validation rules for each of these..=
.<br><br>Hope this helps.<br></div></div><div dir=3D"ltr"><hr><span style=
=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">De : </=
span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a href=
=3D"mailto:[email protected]" target=3D"_blank">dennis.vre=
[email protected] [domaindrivendesign]</a></span><br><span style=3D"font-fam=
ily:Calibri,sans-serif;font-size:11pt;font-weight:bold">Envoy=C3=A9 : </spa=
n><span style=3D"font-family:Calibri,sans-serif;font-size:11pt">=E2=80=8E21=
/=E2=80=8E06/=E2=80=8E2016 22:36</span><br><span style=3D"font-family:Calib=
ri,sans-serif;font-size:11pt;font-weight:bold">=C3=80=C2=A0: </span><span s=
tyle=3D"font-family:Calibri,sans-serif;font-size:11pt"><a href=3D"mailto:do=
[email protected]" target=3D"_blank">domaindrivendesign@yaho=
ogroups.com</a></span><br><span style=3D"font-family:Calibri,sans-serif;fon=
t-size:11pt;font-weight:bold">Objet : </span><span style=3D"font-family:Cal=
ibri,sans-serif;font-size:11pt">[domaindrivendesign] How to model this beha=
viour on multiple aggregates?</span><br><br></div>
<span>=C2=A0</span>






    <div>
=20=20=20=20=20=20
=20=20=20=20=20=20
      <p>We currently have a model where a single aggregate models a Person=
 (identification, address, etc) and his/her personal relationships (marriag=
e, partnership, divorces, etc.). This aggregate is fairly large and not all=
 use cases interested in the relations where operating on the Person aggreg=
ate, we are looking at the consequences of splitting this in two aggregates=
 (Person and PersonRelation for instance).<br><br>As a consequence, there i=
s no possibility to implement something like Person.marriesTo(Person.Id ano=
therPerson). 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 cann=
ot 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 relatio=
nships.<br><br>We have identified the following options on how to implement=
 this but are not satisfied with any of them:<br>* Create a domain service.=
 This feels unnatural as the behaviour is not part of the Person that is ma=
rrying.<br>* Implement the behaviour on Person and provide a list of curren=
t relationships, e.g. Person.marriesTo(PersonId anotherPerson, List&lt;Rela=
tion&gt; currentRelations). This enables the Person to implement the requir=
ed behaviour, but also requires some state (a set of aggregates) to be inje=
cted.<br>* Leave the orchestration to the use case implementing the behavio=
ur. This also seems wrong, as the domain should be responsible for maintain=
ing its integrity. A use case creating duplicate relationships cannot be pr=
evented by the domain when using this option.<br>* Inject the Relation repo=
sitory into Person, so existing Relation instances can be requested as part=
 of the implementation. As I understood, this is bad practice as well.<br><=
br>As this seems a rather general problem, I am curious on how you guys wou=
ld model this.<br></p><p><span><br></span></p><p></p>


    <p></p></div>
=20=20=20=20=20


=20=20=20=20










=20=20












<p></p>

    </div>
=20=20=20=20=20

=20=20=20=20
    <div style=3D"color:#fff;min-height:0"></div>


</div>



=20=20






</blockquote></div><br></div>




<!-- |**|begin egp html banner|**| -->

<br>


<br>

<!-- |**|end egp html banner|**| -->


<div width=3D"1" style=3D"color: white; clear: both;"/>__._,_.___</div>

=20=20=20=20=20=20
=20=20

=20=20=20=20
    <div id=3D"fromDMARC" style=3D"clear:both; margin-top: 10px;">
         <hr style=3D"height:2px ; border-width:0; color:#E3E3E3; backgroun=
d-color:#E3E3E3;">
         Posted by: Remy Fannader &lt;[email protected]&gt;         <hr sty=
le=3D"height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;=
">
    </div>
<!-- Start Recommendations -->
<!-- End Recommendations -->



<!-- |**|begin egp html banner|**| -->

  <img src=3D"http://geo.yahoo.com/serv?s=3D97476590/grpId=3D8116923/grpspI=
d=3D1705007181/msgId=3D24779/stime=3D1466653892" width=3D"1" height=3D"1"> =
<br>

<!-- |**|end egp html banner|**| -->

=20=20
<!-- |**|begin egp html banner|**| -->

<br>



=20=20=20
=20=20=20=20=20
=20
        <!-- |**|begin egp html banner|**| -->
        <div id=3D"ygrp-vital" style=3D"background-color: #f2f2f2; font-fam=
ily: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;">

        <span id=3D"vithd" style=3D"font-weight: bold; color: #333; text-tr=
ansform: uppercase; "><a href=3D"https://groups.yahoo.com/neo/groups/domain=
drivendesign/info;_ylc=3DX3oDMTJlcGJqNWFlBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5Mj=
MEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQ2NjY1Mzg5Mg--"=
 style=3D"text-decoration: none;">Visit Your Group</a></span>

     <ul style=3D"list-style-type: none; margin: 0; padding: 0; display: in=
line;">
                                                    </ul>
  </div>


<div id=3D"ft" style=3D"font-family: Arial; font-size: 11px; margin-top: 5p=
x; padding: 0 2px 0 0; clear: both;">
  <a href=3D"https://groups.yahoo.com/neo;_ylc=3DX3oDMTJkYTRjYWhhBF9TAzk3ND=
c2NTkwBGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwNmdHIEc2xrA2dmcARzd=
GltZQMxNDY2NjUzODky" style=3D"float: left;"><img src=3D"http://l.yimg.com/r=
u/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height=3D"15"=
 width=3D"137" alt=3D"Yahoo! Groups" style=3D"border: 0;"/></a>
  <div style=3D"color: #747575; float: right;"> &bull; <a href=3D"https://i=
nfo.yahoo.com/privacy/us/yahoo/groups/details.html" style=3D"text-decoratio=
n: none;">Privacy</a> &bull; <a href=3D"mailto:domaindrivendesign-unsubscri=
[email protected]?subject=3DUnsubscribe" style=3D"text-decoration: none;">=
Unsubscribe</a> &bull; <a href=3D"https://info.yahoo.com/legal/us/yahoo/uto=
s/terms/" style=3D"text-decoration: none;">Terms of Use</a> </div>
</div>

<!-- |**|end egp html banner|**| -->

  </div> <!-- ygrp-msg -->

=20=20=20


  <br>

<!-- |**|end egp html banner|**| -->


<div style=3D"color: white; clear: both;"/>__,_._,___</div>
</body>

</html>

--94eb2c1477d2b3ee730535e9f764--