tag:blogger.com,1999:blog-5659866753486893848.post4234054085127004623..comments2023-03-27T05:06:59.983-04:00Comments on scabl: Advancing Enterprise DDD - Reinstating the AggregateUnknownnoreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5659866753486893848.post-7366714168517335532019-01-26T11:32:33.086-05:002019-01-26T11:32:33.086-05:00Hi Nikki,
Thanks for the kind words and the excel...Hi Nikki,<br /><br />Thanks for the kind words and the excellent question. It's been a while since I wrote this, but I'll do my best to answer. In DDD, the entity aggregate behaves as a unit of persistence. The root entity acts as the point of access for operations such as create, retrieve, and update. In JPA, the natural way to model this would be having a repository class for each root entity. This makes repository classes for non root entities superfluous at best, and potentially harmful as well.<br /><br />Let's look at some typical repository operations. Retrieve by ID does not make sense for a non root entity, because non root entities do not have identity (i.e., IDs) outside of their aggregate. Create and update are potentially harmful, because they risk breaking intra-aggregate dependencies (discussed somewhere in this series).<br /><br />Ideally, retrieval and updates to non root entities should be managed at the aggregate level, via the repository for the root aggregate. There are some difficulties making this work with JPA, and I discuss these somewhere in this series as well.<br /><br />I hope this helps Nikki.<br /><br />Best, John John Sullivanhttps://www.blogger.com/profile/04223436956380813739noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-70799965388412665722019-01-25T11:41:55.895-05:002019-01-25T11:41:55.895-05:00Hi John and thanks for your wonderful blog
Stuck ...Hi John and thanks for your wonderful blog<br /><br />Stuck within Java/JPA-project I have one question about the comment "Nothing prevents a repository class for a non-root entity". Can you explain why this is bad? I'm not challenging you, just want to know better<br /><br />thanks! Anonymoushttps://www.blogger.com/profile/07164871037864388683noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-41151488199725520082017-04-03T14:38:37.402-04:002017-04-03T14:38:37.402-04:00For our project we simply mapped the entities away...For our project we simply mapped the entities away completely. This required an extra mapping layer between JPA entity and domain but it eliminated all of the usual jpa headachesAnonymoushttps://www.blogger.com/profile/08826824331187796123noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-39070134598498371242016-08-10T20:33:54.635-04:002016-08-10T20:33:54.635-04:00Hi Lucas! Thanks so much for your comments. I'...Hi Lucas! Thanks so much for your comments. I'm really, really glad that you find this series so useful. I considered putting the material into a book format, but honestly, all my best material is available here for free now! ;-) Also, as soon as I finished this series, I switched my focus to the longevity project, which is sort of a JPA replacement but for Scala and NoSQL. The project is going great! Take a look for yourself:<br /><br />http://longevityframework.github.io/longevity/<br /><br />Thanks again Lucas!<br /><br />Best, JohnJohn Sullivanhttps://www.blogger.com/profile/04223436956380813739noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-79649936564684615332016-08-09T09:16:53.831-04:002016-08-09T09:16:53.831-04:00Hello Jhon!
Thank you! Of all the tons of documen...Hello Jhon!<br /><br />Thank you! Of all the tons of documents/samples/tips and everything else you can find online, this is the first time that I read (and understand at the first sight) how to use JPA/Hibernate in the context of DDD. <br /><br />I've read the last 6 (or more) posts one after the other and at every step my doubts of doing DDD with JPA are fading away. <br /><br />I would suggest you to write a book!<br /><br />Thank you!<br />Luca Lucashttps://www.blogger.com/profile/14817321600848747061noreply@blogger.com