tag:blogger.com,1999:blog-5659866753486893848.post8681075960028007672..comments2023-03-27T05:06:59.983-04:00Comments on scabl: Advancing Enterprise DDD - The POJO MythUnknownnoreply@blogger.comBlogger4125tag: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-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.com