tag:blogger.com,1999:blog-20576845.post4976440352006489792..comments2024-03-15T16:44:45.322+01:00Comments on Ziobrando's Lair: About Entities, Aggregates and Data Duplication.Anonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-20576845.post-90211894855445058452011-10-12T15:03:09.238+02:002011-10-12T15:03:09.238+02:00Wow... Thanks Mohamed! :-)Wow... Thanks Mohamed! :-)Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-59533366958265865972011-10-12T14:40:08.377+02:002011-10-12T14:40:08.377+02:00Great post, one of the best article I have ever re...Great post, one of the best article I have ever read, what mostly I like about it, your style of exposing the concept and the way you promote and describe your idea<br /><br />Really thanksAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-20576845.post-61297936867647405402010-08-13T18:30:13.081+02:002010-08-13T18:30:13.081+02:00No, that relation is quite relaxed. If we limit th...No, that relation is quite relaxed. If we limit the exploration to only the stories included in the example, that's it!<br /><br />In a more complex scenario, you'll still might want to retrieve the Customer from the Order. You could store the <b>Customer</b> id in <b>CustomerData</b>, for example. It really depends on your specific business case. Reeference are not forbidden, but in general you can't expect the <b>Customer</b> to be consistent with what's inside the <b>Order</b> aggregate. <br /><br />... but beware: this decoupling is hard to achieve and easy to lose.Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-39986713495367190812010-08-03T15:27:29.768+02:002010-08-03T15:27:29.768+02:00On the last diagram there is no relationship betwe...On the last diagram there is no relationship between Order and Customer - is this an oversight?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20576845.post-87386600287417425212010-06-16T23:23:23.156+02:002010-06-16T23:23:23.156+02:00The short answer is "Use Domain Events",...The short answer is "Use Domain Events", for a longer answer ... I am working on the next post. :-)Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-4053320357923245352010-06-16T18:27:49.326+02:002010-06-16T18:27:49.326+02:00Thank you for a great blog post!
When handling th...Thank you for a great blog post!<br /><br />When handling the duplication between the aggregates. Is there any good practice to keep them both in sync?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20576845.post-38217153823441317572010-06-16T13:02:09.919+02:002010-06-16T13:02:09.919+02:00Hi Andrea,
I basically tried to dig into the pro...Hi Andrea, <br /><br />I basically tried to dig into the problem of "A Customer seem to belong to 2 aggregates", not the whole discussion.<br /><br />1) You're right on the no-methods remark. I probably tried to make it too simple, or gave some thing for granted. But I was also trying to make the point that <i>"there's more to behavior than methods"</i>, I intentionally used the word lifecycle instead: behavior is even more powerful in showing up that concepts are different, but the need for two classes arose even without considering it.<br /><br />2)Quick answer. Repositories were part of the original discussion, but not of the problem I wanted to show here (it ended up being longer than I expected). But Repositories fit in quite easily... just one per aggregate.Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-44314261124167122542010-06-16T12:50:52.229+02:002010-06-16T12:50:52.229+02:00The example is very clear (we can always bank on t...The example is very clear (we can always bank on this) so first of all thanks for taking the time to condense everything that was written in the list in such an organic way.<br /><br />That said, let me play the devil's advocate (partly for discussion's sake, partly for a small provocation, but don't take these as negative remarks):<br /><br />1. I found it curious that all your class diagrams contain properties but not methods... would you please elaborate on this? Or are you just trying to trick us into the common modeling pitfall? ;-)<br /><br />2. originally part of the discussion, they seem to have vanished into the blue: how do repositories fit in all this?<br /><br />...I'm not bad, I'm just drawn that way :-)Anonymoushttps://www.blogger.com/profile/13289303319829436255noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-8665419945266365752010-06-16T11:16:17.921+02:002010-06-16T11:16:17.921+02:00Should be ok right now.Should be ok right now.Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-91397303321914685302010-06-16T11:02:45.028+02:002010-06-16T11:02:45.028+02:00Hi Fabio.
You're right. Thanks for the feedba...Hi Fabio.<br /><br />You're right. Thanks for the feedback :-(, same behavior on Firefox. I used a different editor to write this post and discovered this nice feature with larger images.<br /><br />The workaround while I try to fix this one is to open the images in a different page. SorryAnonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-71792622734221018312010-06-16T10:36:39.968+02:002010-06-16T10:36:39.968+02:00On chrome the image are cutted by the right column...On chrome the image are cutted by the right column. Seem like the central column is too short, or the images must downfitfabio boldrinihttps://www.blogger.com/profile/05401842900802639431noreply@blogger.com