tag:blogger.com,1999:blog-5659866753486893848.comments2023-03-27T05:06:59.983-04:00scablUnknownnoreply@blogger.comBlogger30125tag:blogger.com,1999:blog-5659866753486893848.post-18752871158103110992021-04-27T11:16:06.075-04:002021-04-27T11:16:06.075-04:00Thanks Mustapha!Thanks Mustapha!John Sullivanhttps://www.blogger.com/profile/04223436956380813739noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-32377344976856589102021-04-22T15:03:57.553-04:002021-04-22T15:03:57.553-04:00Impressive seriesImpressive seriesMustapha Hadidhttps://www.blogger.com/profile/09422940770176871907noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-29693898306394039592021-01-19T04:50:42.073-05:002021-01-19T04:50:42.073-05:00Thanks a lot for sharing this. All the best.
IvanThanks a lot for sharing this. All the best.<br />IvanAnonymoushttps://www.blogger.com/profile/04022624214819183212noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-35553133171158477282019-08-27T11:23:26.216-04:002019-08-27T11:23:26.216-04:00This comment has been removed by a blog administrator.Anonymoushttps://www.blogger.com/profile/08731816007441664103noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-89081527317971902192019-06-11T09:14:05.109-04:002019-06-11T09:14:05.109-04:00Great posts! CongratsGreat posts! CongratsRafahttps://www.blogger.com/profile/08702205090261571955noreply@blogger.comtag: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-71798265523332280452018-04-05T05:43:41.165-04:002018-04-05T05:43:41.165-04:00This comment has been removed by a blog administrator.shaluhttps://www.blogger.com/profile/17578776534206677789noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-34113685081794219182017-11-02T21:31:13.003-04:002017-11-02T21:31:13.003-04:00Hi pinkpanther,
I'm glad you liked the articl...Hi pinkpanther,<br /><br />I'm glad you liked the article. You ask a good question about the foreign key relationship. In later articles in this series - starting with "Reinstating the Aggravate" http://scabl.blogspot.com/2015/04/aeddd-9.html - we distinguish between between two kinds of relationships that are typically represented as foreign key relationships in relational databases: those internal to a single entity aggregate, and relationships between aggregates. Relationships between entities within the same aggregate should generally not be represented as key-based relationships in the domain model. They are better modelled by _containment_, or objects nested within other objects. Relationships between aggregates should be represented at the domain level via domain keys. These domain keys can be mapped onto a database model in different ways; for relational databases, a foreign key relationship is appropriate.John Sullivanhttps://www.blogger.com/profile/04223436956380813739noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-64866266742343362572017-11-02T01:27:41.039-04:002017-11-02T01:27:41.039-04:00Hello John,
Thanks for this article.
I would li...Hello John, <br /><br />Thanks for this article.<br /><br />I would like to know, if foreign key relationships are mapped with domain keys as opposed to database keys in the schema.<br /><br />Thank youpinkpantherhttps://www.blogger.com/profile/17627953395443193451noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-64627875271436047222017-07-20T21:31:20.181-04:002017-07-20T21:31:20.181-04:00Your article is very interesting.
Often when we br...Your article is very interesting.<br />Often when we break into a paradigm without understanding its philosophical dimension, we may lose interesting solutions that lie outside of itAnonymoushttps://www.blogger.com/profile/13434649465666709623noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-55399763950121420022017-07-07T07:08:48.714-04:002017-07-07T07:08:48.714-04:00This comment has been removed by a blog administrator.cinek433https://www.blogger.com/profile/06480790288824036057noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-57845246687443684792017-06-23T05:05:32.769-04:002017-06-23T05:05:32.769-04:00This comment has been removed by a blog administrator.Karthika Shreehttps://www.blogger.com/profile/06515257484162457182noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-37250759115440562652017-06-12T11:18:17.853-04:002017-06-12T11:18:17.853-04:00Release is out: http://scabl.blogspot.com/2017/06/...Release is out: http://scabl.blogspot.com/2017/06/longevity-release-023-use-type-classes.htmlJohn Sullivanhttps://www.blogger.com/profile/04223436956380813739noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-55025051415614291642017-06-09T16:34:49.638-04:002017-06-09T16:34:49.638-04:00Thank you Tai!Thank you Tai!John Sullivanhttps://www.blogger.com/profile/04223436956380813739noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-90217858655740570932017-06-09T15:57:35.967-04:002017-06-09T15:57:35.967-04:00Thanks for allThanks for allAnonymoushttps://www.blogger.com/profile/02212217799014742115noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-28700395076661830462017-06-09T12:55:11.012-04:002017-06-09T12:55:11.012-04:00Just a quick note to say that the code for this wo...Just a quick note to say that the code for this work is in longevity master branch here: https://github.com/longevityframework/longevity<br /><br />It will appear in the longevity 0.23 release, which should be out by Monday at the latest. This means the user manual on the website does not reflect these changes yet:<br /><br />http://longevityframework.org/manual/John Sullivanhttps://www.blogger.com/profile/04223436956380813739noreply@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-10559744429381778962016-09-28T13:58:37.705-04:002016-09-28T13:58:37.705-04:00This is awesomeThis is awesomeAnonymoushttps://www.blogger.com/profile/12573276166203766055noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-2434908496593605472016-08-11T10:31:54.907-04:002016-08-11T10:31:54.907-04:00Thanks for your insightful comment Gregory!
If yo...Thanks for your insightful comment Gregory!<br /><br />If you are doing DDD with a NoSQL database please consider longevity, a Persistence Framework for Scala and NoSQL with a Domain Driven Design Orientation.<br /><br />http://longevityframework.github.io/longevity/<br /><br />Best, JohnJohn Sullivanhttps://www.blogger.com/profile/04223436956380813739noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-50729310545521268342016-08-11T09:29:11.743-04:002016-08-11T09:29:11.743-04:00Thank you for sharing this point of view.
I compl...Thank you for sharing this point of view. <br />I completely agree with you and I'm sharing a similar message within my DDD experience: you have to separate the conceptual model (only domain classes and its relationships) to the logical model of the persistent stores (database schemas).<br /><br />This is especially true for NoSQL solutions such as Cassandra or Redis where Data Modeling is an important and dedicated activity with query driven schema design (you have to model your data among your data access patterns). <br />From a DDD point of view, it is the responsability of the infrastrcture layer to define mappers (or converters) between these two different models and call them in the repository implementations.<br /><br />Regarding the DDD identifier, I agree of the importance to find a right unique domain identifier (and make it part of the ubiquitous language), despite to fall back to a technical identifier from the persistence store.<br /><br />Regarding diagnostic fields, there are no issues from my point of view. At the begining, these technical fields are not part of the ubiquitous language (and so not part of the domain model) <br />Either you need to define another Bounded Context (BC), maybe a dedicated Diagnostic BC, either these technical fields are hidden by the infrastructure layer. Therefore, this use case of mixing diagnotic fields with true domain fields in the domain model can't take place in an unique BC (into POJO domain model).Gregory Boissinot's Bloghttps://www.blogger.com/profile/03190372197505487704noreply@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.comtag:blogger.com,1999:blog-5659866753486893848.post-7398659865513709652016-07-18T16:14:48.389-04:002016-07-18T16:14:48.389-04:00The blog is at https://simbo1905.wordpress.com/201...The blog is at https://simbo1905.wordpress.com/2016/07/18/domain-driven-design-entities-value-objects-aggregates-and-roots-with-jpa-part-4/ and the sample code is at https://github.com/simbo1905/root-objectssimbo1905https://www.blogger.com/profile/03888364220130134729noreply@blogger.comtag:blogger.com,1999:blog-5659866753486893848.post-49855963834449084862016-07-18T16:13:47.929-04:002016-07-18T16:13:47.929-04:00An excellent post. In a blog and accompanying samp...An excellent post. In a blog and accompanying sample code "domain-driven-design-entities-value-objects-aggregates-and-roots-with-jpa-part-4" I argue that everything to dow with a root entity and the aggregate that it contains should be in a single Java package. A mini-service class, call it a store, can exist that just focuses on containing the JPA complexity of finding, loading and saving root entities by dealing with the entity manager and orchestrating a number of JPA repository classes. simbo1905https://www.blogger.com/profile/03888364220130134729noreply@blogger.com