RE: How to model this behaviour on multiple aggregates?
"Rénald VENANT-VALERY [email protected] [domaindrivendesign]" <[email protected]> Wed, 22 Jun 2016 09:39:39 +0200
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <[email protected]> |
--_2239EF74-9DAB-44EC-8435-8AB372BFC29E_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Once we had some needs similar to yours.
On the persistence side, we creat=
ed a "third store" in a relational database to be able to consolidate and d=
eduplicate data. We created a "roles table" to link all thirds together. An=
item of this table is composed of the following information :
{ RoleId, Th=
ird1Id, Third2Id, ValidityStartDate, ValidityEndDate }, with light validati=
on rules.
The software repository is giving us a graph of connected thirds=
, expressed in clear business language (Ubiquitous Language) :
{ Client, Ad=
dress, { Spouse , Employer }}
Complete validation occurs in the Client agg=
regate root... this allow us to manage many different graphs with specific =
validation rules for each of these...
Hope this helps.
-----Message d'or=
igine-----
De : "[email protected] [domaindrivendesign]" <domaindr=
[email protected]>
Envoy=C3=A9 : =E2=80=8E21/=E2=80=8E06/=E2=80=8E=
2016 22:36
=C3=80=C2=A0: "[email protected]" <domaindriven=
[email protected]>
Objet : [domaindrivendesign] How to model this beha=
viour on multiple aggregates?
We currently have a model where a single =
aggregate models a Person (identification, address, etc) and his/her person=
al relationships (marriage, partnership, divorces, etc.). This aggregate is=
fairly large and not all use cases interested in the relations where opera=
ting on the Person aggregate, we are looking at the consequences of splitti=
ng this in two aggregates (Person and PersonRelation for instance).
As a c=
onsequence, there is no possibility to implement something like Person.marr=
iesTo(Person.Id anotherPerson). The reason is the constraint that this is o=
nly allowed as long as this relation is not already present at the given mo=
ment (A Person cannot be married twice at the same time). This is just an e=
xample but there a number of constraints on the model with respect to a Per=
son and his relationships.
We have identified the following options on how=
to implement this but are not satisfied with any of them:
* Create a domai=
n 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 requi=
red behaviour, but also requires some state (a set of aggregates) to be inj=
ected.
* Leave the orchestration to the use case implementing the behaviour=
. This also seems wrong, as the domain should be responsible for maintainin=
g its integrity. A use case creating duplicate relationships cannot be prev=
ented by the domain when using this option.
* Inject the Relation repositor=
y into Person, so existing Relation instances can be requested as part of t=
he 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 th=
is.
--_2239EF74-9DAB-44EC-8435-8AB372BFC29E_
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;">Once =
we had some needs similar to yours.<br><br>On the persistence side, we crea=
ted 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. A=
n item of this table is composed of the following information :<br>{ RoleId=
, Third1Id, Third2Id, ValidityStartDate, ValidityEndDate }, with light vali=
dation rules.<br><br>The software repository is giving us a graph of connec=
ted thirds, expressed in clear business language (Ubiquitous Language) :<br=
>{ Client, Address, { Spouse , Employer }}<br><br>Complete validation occur=
s in the Client aggregate root... this allow us to manage many different gr=
aphs with specific validation rules for each of these...<br><br>Hope this h=
elps.<br></div></div><div dir=3D"ltr"><hr><span style=3D"font-family: Calib=
ri,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:do=
[email protected]">[email protected] [domaindrivend=
esign]</a></span><br><span style=3D"font-family: Calibri,sans-serif; font-s=
ize: 11pt; font-weight: bold;">Envoy=C3=A9 : </span><span style=3D"font-fam=
ily: Calibri,sans-serif; font-size: 11pt;">=E2=80=8E21/=E2=80=8E06/=E2=80=
=8E2016 22:36</span><br><span style=3D"font-family: Calibri,sans-serif; fon=
t-size: 11pt; font-weight: bold;">=C3=80 : </span><span style=3D"font-=
family: Calibri,sans-serif; font-size: 11pt;"><a href=3D"mailto:domaindrive=
[email protected]">[email protected]</a></span><br><=
span style=3D"font-family: Calibri,sans-serif; font-size: 11pt; font-weight=
: bold;">Objet : </span><span style=3D"font-family: Calibri,sans-serif; fon=
t-size: 11pt;">[domaindrivendesign] How to model this behaviour on multiple=
aggregates?</span><br><br></div>
<span style=3D"display: none;"> </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<Rela=
tion> 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 <corba=
[email protected]> <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=3D24778/stime=3D1466634516" 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=3DX3oDMTJlMjB0cGprBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5Mj=
MEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQ2NjYzNDUxNQ--"=
style=3D"text-decoration: none;">Visit Your Group</a></span>
<ul style=3D"list-style-type: none; margin: 0; padding: 0; display: in=
line;">
<li style=3D"border-right: 1px solid #000; font-weight: 700; di=
splay: inline; padding: 0 5px; margin-left: 0;">
<span class=3D"cat"><a href=3D"https://groups.yahoo.com/neo/groups/do=
maindrivendesign/members/all;_ylc=3DX3oDMTJmdmtkMHRyBF9TAzk3MzU5NzE0BGdycEl=
kAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzE0Nj=
Y2MzQ1MTU-" style=3D"text-decoration: none;">New Members</a></span>
<span class=3D"ct" style=3D"color: #ff7900;">1</span>
</li>
</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=3DX3oDMTJkYTBvZ2pmBF9TAzk3ND=
c2NTkwBGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwNmdHIEc2xrA2dmcARzd=
GltZQMxNDY2NjM0NTE2" 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;"> • <a href=3D"https://i=
nfo.yahoo.com/privacy/us/yahoo/groups/details.html" style=3D"text-decoratio=
n: none;">Privacy</a> • <a href=3D"mailto:domaindrivendesign-unsubscri=
[email protected]?subject=3DUnsubscribe" style=3D"text-decoration: none;">=
Unsubscribe</a> • <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>
--_2239EF74-9DAB-44EC-8435-8AB372BFC29E_--