DDD persistence through non-orm tools in java

Question

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)

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.