RE: How to model this behaviour on multipleaggregates?

"Rénald VENANT-VALERY [email protected] [domaindrivendesign]" <[email protected]> Fri, 24 Jun 2016 21:58:28 +0200
Newsgroups gmane.comp.programming.domain-driven-design
Message-ID <[email protected]> 
--_41171F2B-BEEA-45FD-BC81-4982F6CC7B7C_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Maybe, depending on the complexity of you system, do you need to manage the=
 thirds graph in a specific application. A "thirds repository". And to ensu=
re the graphs injected in your business are read-only. They should be modif=
ied from a central source, because modifying relationships will have an imp=
act on both ends of the relation and may be cascading dangerously. As statu=
s and relationships between thirds may be complex (human and administrative=
 errors, etc...), that kind of purpose should be administrated by someone (=
a real person) with some experience in this matter. So, I'd say : 2 aggrega=
tes, 2 applications, one deals with read-only information, the other deals =
with administrating this data.


-----Message d'origine-----
De : "dennis.vr=
[email protected] [domaindrivendesign]" <[email protected]=
>
Envoy=C3=A9 : =E2=80=8E21/=E2=80=8E06/=E2=80=8E2016 22:41
=C3=80=C2=A0: "=
[email protected]" <[email protected]>
Ob=
jet : [domaindrivendesign] How to model this behaviour on multipleaggregate=
s?


  
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 u=
se cases interested in the relations where operating on the Person aggregat=
e, we are looking at the consequences of splitting this in two aggregates (=
Person and PersonRelation for instance).


As a consequence, there is no pos=
sibility to implement something like Person.marriesTo(Person.Id anotherPers=
on). 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 ma=
rried twice at the same time). This is just an example but there a number o=
f 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 unnat=
ural as the behaviour is not part of the Person that is marrying.
* Impleme=
nt 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 req=
uires some state (a set of aggregates) to be injected.
* Leave the orchestr=
ation 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 us=
ing this option.
* Inject the Relation repository into Person, so existing =
Relation instances can be requested as part of the implementation. As I und=
erstood, this is bad practice as well.


As this seems a rather general prob=
lem, I am curious on how you guys would model this.







--_41171F2B-BEEA-45FD-BC81-4982F6CC7B7C_
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>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"></=
head>












=20
<body style=3D"background-color: rgb(255, 255, 255);">


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

<br><br>

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


<div><div style=3D"font-family: Calibri,sans-serif; font-size: 11pt;">Maybe=
, depending on the complexity of you system, do you need to manage the thir=
ds graph in a specific application. A "thirds repository". And to ensure th=
e graphs injected in your business are read-only. They should be modified f=
rom a central source, because modifying relationships will have an impact o=
n both ends of the relation and may be cascading dangerously. As status and=
 relationships between thirds may be complex (human and administrative erro=
rs, etc...), that kind of purpose should be administrated by someone (a rea=
l person) with some experience in this matter. So, I'd say : 2 aggregates, =
2 applications, one deals with read-only information, the other deals with =
administrating this data.</div></div><div dir=3D"ltr"><hr><span style=3D"fo=
nt-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">De : </=
span><span style=3D"font-family: Calibri,sans-serif; font-size: 11pt;"><a h=
ref=3D"mailto:[email protected]">[email protected]=
m [domaindrivendesign]</a></span><br><span style=3D"font-family: Calibri,sa=
ns-serif; font-size: 11pt; font-weight: bold;">Envoy=C3=A9 : </span><span s=
tyle=3D"font-family: Calibri,sans-serif; font-size: 11pt;">=E2=80=8E21/=E2=
=80=8E06/=E2=80=8E2016 22:41</span><br><span style=3D"font-family: Calibri,=
sans-serif; font-size: 11pt; font-weight: bold;">=C3=80&nbsp;: </span><span=
 style=3D"font-family: Calibri,sans-serif; font-size: 11pt;"><a href=3D"mai=
lto:[email protected]">[email protected]<=
/a></span><br><span style=3D"font-family: Calibri,sans-serif; font-size: 11=
pt; font-weight: bold;">Objet : </span><span style=3D"font-family: Calibri,=
sans-serif; font-size: 11pt;">[domaindrivendesign] How to model this behavi=
our on multipleaggregates?</span><br><br></div>
<span style=3D"display: none;">&nbsp;</span>






    <div id=3D"ygrp-text">
=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><span><br class=3D"yui-cursor"></span></p><p></p>


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


=20=20=20=20










  <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;
}
  #ygrp-sponsor #ygrp-lc {
  font-family: Arial;
}


#ygrp-sponsor #ygrp-lc #hd {
  margin: 10px 0px;
  font-weight: 700;
  font-size: 78%;
  line-height: 122%;
}


#ygrp-sponsor #ygrp-lc .ad {
  margin-bottom: 10px;
  padding: 0 0;
}


  #actions {
    font-family: Verdana;
    font-size: 11px;
    padding: 10px 0;
  }


  #activity {
    background-color: #e0ecee;
    float: left;
    font-family: Verdana;
    font-size: 10px;
    padding: 10px;
  }


  #activity span {
    font-weight: 700;
  }


  #activity span:first-child {
    text-transform: uppercase;
  }


  #activity span a {
    color: #5085b6;
    text-decoration: none;
  }


  #activity span span {
    color: #ff7900;
  }


  #activity span .underline {
    text-decoration: underline;
  }


  .attach {
    clear: both;
    display: table;
    font-family: Arial;
    font-size: 12px;
    padding: 10px 0;
    width: 400px;
  }


  .attach div a {
    text-decoration: none;
  }


  .attach img {
    border: none;
    padding-right: 5px;
  }


  .attach label {
    display: block;
    margin-bottom: 5px;
  }


  .attach label a {
    text-decoration: none;
  }
=20=20
  blockquote {
    margin: 0 0 0 4px;
  }


  .bold {
    font-family: Arial;
    font-size: 13px;
    font-weight: 700;
  }


  .bold a {
    text-decoration: none;
  }


  dd.last p a {
    font-family: Verdana;
    font-weight: 700;
  }


  dd.last p span {
    margin-right: 10px;
    font-family: Verdana;
    font-weight: 700;

  }


  dd.last p span.yshortcuts {
    margin-right: 0;
  }


  div.attach-table div div a {
    text-decoration: none;
  }


  div.attach-table {
    width: 400px;
  }


  div.file-title a, div.file-title a:active, div.file-title a:hover, div.fi=
le-title a:visited {
    text-decoration: none;
  }


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


  div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
    font-family: Verdana;
    font-size: 10px;
    font-weight: normal;
  }


  .green {
    color: #628c2a;
  }


  .MsoNormal {
    margin: 0 0 0 0;
  }


  o {
    font-size: 0;
  }


  #photos div {
    float: left;
    width: 72px;
  }


  #photos div div {
    border: 1px solid #666666;
    height: 62px;
    overflow: hidden;
    width: 62px;
  }


  #photos div label {
    color: #666666;
    font-size: 10px;
    overflow: hidden;
    text-align: center;
    white-space: nowrap;
    width: 64px;
  }


  #reco-category {
    font-size: 77%;
  }


  #reco-desc {
    font-size: 77%;
  }


  .replbq {
    margin: 4px;
  }


  #ygrp-actbar div a:first-child {
   /* border-right: 0px solid #000;*/
    margin-right: 2px;
    padding-right: 5px;
  }


  #ygrp-mlmsg {
    font-size: 13px;
    font-family: Arial, helvetica,clean, sans-serif;
    *font-size: small;
    *font: x-small;
  }


  #ygrp-mlmsg table {
    font-size: inherit;
    font: 100%;
  }


  #ygrp-mlmsg select, input, textarea {
    font: 99% Arial, Helvetica, clean, sans-serif;
  }


  #ygrp-mlmsg pre, code {
    font:115% monospace;
    *font-size:100%;
  }


  #ygrp-mlmsg * {
    line-height: 1.22em;
  }


  #ygrp-mlmsg #logo {
    padding-bottom: 10px;
  }




  #ygrp-msg p a {

    font-family: Verdana;
  }


  #ygrp-msg p#attach-count span {
    color: #1E66AE;
    font-weight: 700;
  }


  #ygrp-reco #reco-head {
    color: #ff7900;
    font-weight: 700;
  }


  #ygrp-reco {
    margin-bottom: 20px;

    padding: 0px;
  }


  #ygrp-sponsor #ov li a {
    font-size: 130%;
    text-decoration: none;
  }


  #ygrp-sponsor #ov li {
    font-size: 77%;
    list-style-type: square;
    padding: 6px 0;
  }=20


  #ygrp-sponsor #ov ul {
    margin: 0;
    padding: 0 0 0 8px;
  }


  #ygrp-text {
    font-family: Georgia;
  }


  #ygrp-text p {
    margin: 0 0 1em 0;
  }


  #ygrp-text tt {
    font-size: 120%;
  }


  #ygrp-vital ul li:last-child {
    border-right: none !important;=20
  }=20
  -->
  </style>
















<!-- |**|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: =3D?utf-8?Q?R=3DC3=3DA9nald_VENANT-VALERY?=3D &lt;r.ven=
[email protected]&gt;         <hr style=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=3D24780/stime=3D1466808228" width=3D"1" height=3D"1"> =
<br>

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

=20=20=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=3DX3oDMTJlaXAxZWlrBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5Mj=
MEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQ2NjgwODIyOA--"=
 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=3DX3oDMTJkYmcxdHVkBF9TAzk3ND=
c2NTkwBGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwNmdHIEc2xrA2dmcARzd=
GltZQMxNDY2ODA4MjI4" 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>
--_41171F2B-BEEA-45FD-BC81-4982F6CC7B7C_--