Re: Working with domain events. Referencing leaf / sub-entity of aggregate

--001a113635d8f222f90532a89866
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

"Our stakeholder often fall back and say: We need an order and order items.
But this is only because of giving the =E2=80=9Cthing=E2=80=9D an order num=
ber to talk
about. Like brackets around all order items. So our understanding in the
dev-Team is, the order items are aggregates and we will do something to
group then by an order number.

We think of order items as aggregates, because a customer will never
request an order with three items in it. Furthermore he will order three
articles with a specific number. It is only for communication reasons that
a number for these three items makes it easier. What do you think about
that?"


This seems very weird to me that a line item would be an aggregate.

On Thu, May 12, 2016 at 3:56 PM, [email protected] [domaindrivendesign] =
<
[email protected]> wrote:

>
>
> Hello everyone,
>
>
> I know my topic is not new and was discussed many times before. I read a
> lot but not sure whether I am going the best path. So I will place this
> topic here again with another concrete example.
>
>
> In the sales department we work with orders. Obviously this is, what a
> customer orders.
>
>
> A) Understanding an order with its items:
>
> Our stakeholder often fall back and say: We need an order and order items=
.
> But this is only because of giving the =E2=80=9Cthing=E2=80=9D an order n=
umber to talk
> about. Like brackets around all order items. So our understanding in the
> dev-Team is, the order items are aggregates and we will do something to
> group then by an order number.
>
> We think of order items as aggregates, because a customer will never
> request an order with three items in it. Furthermore he will order three
> articles with a specific number. It is only for communication reasons tha=
t
> a number for these three items makes it easier. What do you think about
> that?
>
>
> B) Conflict with sub-entity within order-item-aggregate
>
> Think of order item. This is an article in a specific quantity a customer
> would like to have. Order item is an aggregate. Assigned to the order ite=
m
> there are multiple =E2=80=9Ccall off=E2=80=9D. A call off describes when =
the customer
> requests a certain quantity and whether it must be delivered (DDP) or
> whether it will be fetched (=E2=80=9Cex works=E2=80=9D). Actually call of=
f is an aggregate
> on its own. Here is our conflict:
>
> 1. Sum of quantities for all call off must be less than or equal to order
> item quantity. So making call off an sub entity of order item seems to be
> the best choice, than making it an own aggregate.
>
> 2. On the other side call off will be referenced in the dispatch
> department. This is, because every call off leads at least to an =E2=80=
=9Cgoods
> issue request=E2=80=9D in the dispatch department. But refering to book f=
rom Eric
> Evans it is absolutely not allowed to reference a sub-entity - except for=
 a
> single operation. It is only allowed to reference aggregates.
>
> We are afraid of having 90% our objects being an aggregate and placing
> domain logic not within the aggregates but within services around two or
> more aggregates.
>
>
> From what I have already read and got as responses from experts like Paul
> Rayner I should start to think about "call off" as an "domain event". Oka=
y,
> it's no problem to imagine that order item will have an "customer request=
ed
> quantity"-Event or something like this.
>
>
> Problem is when leaving bounded context of let's say "customer care". In
> dispatch department it is no problem to imagine that this domain event ca=
n
> lead to an action and new aggregate there. At this point I do not need a
> reference to the "call off"/domain event. But when dispatch has problems =
or
> work is done, sales department needs to be informed that "call off" needs
> attention or is done and possibly order item can be given to
> "invocement"-bounded-context?
>
>
> Is it okay, when aggregate in dispatch holds composed key on order item
> and sub-entity / aggregate leaf? What other possibilitites do you see? Mu=
st
> "call off" be an aggregate and a domain-service must check sum of call of=
f
> quantities agains order item? Is this something for the "Process Manager"
> presented to me the first time at the DDD Europe in Belgium by Mathias
> Verraes?
>
>
> I will be very happy getting a lot of ideas and responses. Thank you very
> much for reading my story :-).
>
>
>
>
>=20
>



--=20
Studying for the Turing test

--001a113635d8f222f90532a89866
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">&quot;<span style=3D"font-size:12.8px">Our stakeholder oft=
en fall back and say: We need an order and order items. But this is only be=
cause of giving the =E2=80=9Cthing=E2=80=9D an order number to talk about. =
Like brackets around all order items. So our understanding in the dev-Team =
is, the order items are aggregates and we will do something to group then b=
y an order number.</span><p style=3D"font-size:12.8px"></p><p style=3D"font=
-size:12.8px">We think of order items as aggregates, because a customer wil=
l never request an order with three items in it. Furthermore he will order =
three articles with a specific number. It is only for communication reasons=
 that a number for these three items makes it easier. What do you think abo=
ut that?&quot;</p><p style=3D"font-size:12.8px"><br></p><p style=3D"font-si=
ze:12.8px">This seems very weird to me that a line item would be an aggrega=
te.</p></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On T=
hu, May 12, 2016 at 3:56 PM, <a href=3D"mailto:[email protected]">thiel_=
[email protected]</a> [domaindrivendesign] <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:[email protected]" target=3D"_blank">domaindrivendesi=
[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;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></p><p><span>Hello everyone,</span></p><p><span><br></span></p><p>=
<span>I know my topic is not new and was discussed many times before. I rea=
d a lot but not sure whether I am going the best path. So I will place this=
 topic here again with another concrete example.</span></p><p><span><br></s=
pan></p><p>In the sales department we work with orders. Obviously this is, =
what a customer orders.=C2=A0</p><p><br></p><p>A) Understanding an order wi=
th its items:</p><p>Our stakeholder often fall back and say: We need an ord=
er and order items. But this is only because of giving the =E2=80=9Cthing=
=E2=80=9D an order number to talk about. Like brackets around all order ite=
ms. So our understanding in the dev-Team is, the order items are aggregates=
 and we will do something to group then by an order number.</p><p><span></s=
pan></p><p>We think of order items as aggregates, because a customer will n=
ever request an order with three items in it. Furthermore he will order thr=
ee articles with a specific number. It is only for communication reasons th=
at a number for these three items makes it easier. What do you think about =
that?</p><p><br></p><p>B) Conflict with sub-entity within order-item-aggreg=
ate</p><p>Think of order item. This is an article in a specific quantity a =
customer would like to have. Order item is an aggregate. Assigned to the or=
der item there are <span style=3D"text-decoration:underline">multiple </spa=
n>=E2=80=9Ccall off=E2=80=9D. A call off describes when the customer reques=
ts a certain quantity and whether it must be delivered (DDP) or whether it =
will be fetched (=E2=80=9Cex works=E2=80=9D). Actually call off is an aggre=
gate on its own. Here is our conflict:</p><p>1.<span style=3D"white-space:p=
re-wrap">	</span>Sum of quantities for <span style=3D"text-decoration:under=
line">all </span>call off must be less than or equal to order item quantity=
. So making call off an sub entity of order item seems to be the best choic=
e, than making it an own aggregate.</p><p>2.<span style=3D"white-space:pre-=
wrap">	</span>On the other side call off will be referenced in the dispatch=
 department. This is, because every call off leads at least to an =E2=80=9C=
goods issue request=E2=80=9D in the dispatch department. But refering to bo=
ok from Eric Evans it is absolutely not allowed to reference a sub-entity -=
 except for a single operation. It is only allowed to reference aggregates.=
</p><p>We are afraid of having 90% our objects being an aggregate and placi=
ng domain logic not within the aggregates but within services around two or=
 more aggregates.</p><p><br></p><p>From what I have already read and got as=
 responses from experts like Paul Rayner I should start to think about &quo=
t;call off&quot; as an &quot;domain event&quot;. Okay, it&#39;s no problem =
to imagine that order item will have an &quot;customer requested quantity&q=
uot;-Event or something like this.</p><p><br></p><p>Problem is when leaving=
 bounded context of let&#39;s say &quot;customer care&quot;. In dispatch de=
partment it is no problem to imagine that this domain event can lead to an =
action and new aggregate there. At this point I do not need a reference to =
the &quot;call off&quot;/domain event. But when dispatch has problems or wo=
rk is done, sales department needs to be informed that &quot;call off&quot;=
 needs attention or is done and possibly order item can be given to &quot;i=
nvocement&quot;-bounded-context?</p><p><br></p><p>Is it okay, when aggregat=
e in dispatch holds composed key on order item and sub-entity / aggregate l=
eaf? What other possibilitites do you see? Must &quot;call off&quot; be an =
aggregate and a domain-service must check sum of call off quantities agains=
 order item? Is this something for the &quot;Process Manager&quot; presente=
d to me the first time at the DDD Europe in Belgium by Mathias Verraes?</p>=
<p><br></p><p>I will be very happy getting a lot of ideas and responses. Th=
ank you very much for reading my story :-).</p><p><br></p><div><br></div><p=
><span><br></span></p><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><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr">Studying for the Turing test</div></d=
iv>
</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: Greg Young &lt;[email protected]&gt;         <hr =
style=3D"height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3=
E3;">
    </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=3D24750/stime=3D1463074897" 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=3DX3oDMTJlOWsycDNuBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5Mj=
MEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQ2MzA3NDg5Nw--"=
 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=3DX3oDMTJmdnMzM2wxBF9TAzk3MzU5NzE0BGdycEl=
kAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzE0Nj=
MwNzQ4OTc-" 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=3DX3oDMTJkZzBmaDhlBF9TAzk3ND=
c2NTkwBGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwNmdHIEc2xrA2dmcARzd=
GltZQMxNDYzMDc0ODk3" 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>

--001a113635d8f222f90532a89866--