Replies: 1 comment
-
Similar problem as in this discussion #132 , you shouldn't treat your domain entities as database models. Relations between domain entities should be based on business logic, for example entity A cannot execute business mutations without satisfying the invariant of entity B. In this case we can create an aggregate root that includes both entities A and B. ORM entities are not domain entities though. They are database tables that represent the read model with relations based on data (relational model). I would create a query that just joins multiple tables together, and call this query from your controller to get all the related data that you need. No aggregates involved. You can create your query in one of the existing modules for simplicity, or you can go further into CQRS and separate your app into read and write model:
|
Beta Was this translation helpful? Give feedback.
-
I'll give an example of a Recruitment system. There are the following basic aggregates:
Recruiter
Candidate
Job Vacancy
All of these aggregates interact with some models such as Skill and Location (let's call it the Shared Module)... I've structured it as follows:
/src/modules/shared/skill
/src/modules/shared/location
It also has all the controllers and services like a basic module (because it doesn't have complex logic, so I didn't apply DDD to these modules).
So, in the aggregates I mentioned above, let's assume they all have endpoints to get a list, and in that list, it will include skill data, like the example below:
My current solution is to create ORM entities (using TypeORM sync: false) in the modules: recruiter, candidate, job vacancy. Then, I use relations to join and retrieve skill and location data to get the response data for the example above.
Is this a good approach? I really need your advice.
Have a great day.
Beta Was this translation helpful? Give feedback.
All reactions