So our domain model drove our database and ORMs worked for DDD implementations.

Now the tables have been altered a lot and as a consequence ORM impedence is too much in our domain model to use hibernate tweaks. I am looking at persistence approaches for DDD entites.

  1. Can Cross-reference tables be brought into domain models? they dont really make much sense other that to just persist because there are just ids with type ids and more ids. Probably not gonna work. But still want to know if there are any ways?
  2. Create an Entity in infrastructure and add a persistence layer so that in application layer, I can call domain services. Then write multiple mappers and per table entities and persist the domain entity.
  3. I see many suggest to use reflection like in ORMs? sorry I dont get it. How do we do this? I tried to search but could not find a good example. Can some please suggest how to do this?

orm is used so much that I fear leaving it out would be a mistake.

Domain Model/Entity

  1. Epic (Ag Root) (Id, Name, Start_Date, Due_Date, (lazy) List, EpicStatus) [References another by aggregate root it]
  2. Story (Ag Root) (Id, List, StoryStatus, Assessment (lazy))
  3. Task (Entity) (Id, Resolution, List)
  4. Resolution (vo) (Id, code)
  5. Attachment (vo) (Id)
  6. Epic Status (vo) (Id, code)
  7. Story Status (vo) (Id, code)

I persist each aggregate in domain service that creates Epic, then I get EpicId and persist Story and use Spring Data for repositories

Table Model:

We have Types/Category kind of ref Tables even if there is just 1 value there, so thats more of data that business model doesnt need to care and feels artificial to introduce all those there.

  1. Epic (Epic_Id, Name, Start_Date, Due_Date, Epic_Status_id, Epic_Type_Id)
  2. Story (Story_Id, Epic_Id, Story_Type_Id,Story_Status_Id)
  3. Task_Story_Xref (Task_Source_Id, Story_Id, Task_Type_Id, Task_Resolution_Id) [Lets say a task can belong to multiple story through cloning or something]
  4. Task (Task_Source_Id, Task_Type_Id, Task_Name)
  5. Task_Attachment_Xref (Attachment_ID, Task_Source_Id, Story_Id, Task_Type_Id, Task_Resolution_Id) [Attachment is saved in different microservice]
  6. Reference Tables (Task_Type, Resolution_Type,Epic_Status, Story_Status, Epic_Type, Story_Type etc)
  • Given the simplicity of this domain (6 tables!), my advice to you is "just get it done". This is little more than CRUD with some possible sprinkles of behavior. Afterwards, take a step back, appraise the resulting system, and make tweaks as necessary. You will learn a lot more by "doing" and "redoing" than through any answers you get here. May 17, 2019 at 14:43
  • @king-side-slide its just a snapshot of the model that i presented to depict the it. But you are correct and thats is what I am doing but I do post here to find some techniques useful and adopt it. (I am doing DDD because I worked on a non-persistent system with complicated logic and after modeling domain models the project got completed in a couple weeks. Just soo much clarity once we separate DB logic. Thats why :) )
    – Dexters
    May 17, 2019 at 17:08

1 Answer 1


You haven't provided much detail on what your entities look like, but if normalized tables are causing you trouble, you may be modeling too much in your entity objects. It is considered best practice to keep your aggregates fairly small and reference other aggregates by ID.

If you do this, your repository interfaces will have lookup methods to traverse associations between aggregates. Your repository implementation can use a cross-reference table to traverse the association and you can continue to use your existing ORM to load the resulting entities.

  • I have added some details, but I did go through that article and thats how I modeled domain. I initially had 1 big aggregate, and now 2 aggregates and reference it by id. But still the tables were simple match up so it was less complicated.
    – Dexters
    May 17, 2019 at 8:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.