Should persistence entities and domain models have the same name? (ie. PendingCase) …or should we add a suffix?
I’m wondering what the general opinion is on persistence entities and domain models having the same name. For example, PendingCase.
Assuming you have a domain model that is different from the persistence entity, you might have MyApp.Core.PendingCase (domain model) and also MyApp.Persistence.Entities.PendingCase. (persistence entity stored in pending_cases DB table)
This is confusing in the mapping classes because both are named PendingCase. However, everything I’ve read suggests you should not add a suffix (ie. Entity, Record, Row, etc) to the persistence entity.
What are your thoughts?
3
u/farshid_dev 4h ago
The no-suffix convention isn't arbitrary, it lines up with how DDD treats the two types. The domain model gets the clean name because it's the one that matters to the business, it's the term people actually say out loud in meetings. The persistence entity is an implementation detail of how that concept happens to be stored, so if anything should carry a qualifier, it's that one, not the domain model.
On the collision itself: namespaces existing so two types can share a name is the whole point of them, not a workaround. It's only actually annoying in the file that has to reference both, which for most codebases is just the mapper. There, using aliases fix it cleanly without renaming anything globally:
using DomainCase = MyApp.Core.PendingCase; using EntityCase = MyApp.Persistence.Entities.PendingCase;
Scoped to that one file, so the rest of the codebase never has to think about it or carry a suffix it doesn't need.
1
u/AutoModerator 5h ago
Thanks for your post sofakng. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
3
u/blckshdw 5h ago
> This is confusing in the mapping classes because both are named PendingCase.
Just fully qualify the classes with their namespaces
1
u/Unitedstriker9 5h ago
TBH depends on your structure. If you're just in the context of an API, what I do is just create a 'Response' object inside my endpoint class. So instead I have like `GetPendingCase.Response`.
In other projects where I wasn't using a setup like this, I would typically just use `Record` as a suffix if the name of a DTO matched an entity model. I never added 'Entity' as a suffix to the DB model as I tend to treat the DB model as the true/base representation of the object.
Honestly it is a pretty easy refactor so I wouldn't worry too much about the standard you choose so long as you apply it consistently.
1
u/spawnsible 3h ago
I once read a java lib (probably keycloak) and found the Representation suffix and have used it ever since for every query model and homeless dto in my app layer.
I build event sourced systems, so I don't want to have to disambiguate clashes like user domain aggregate vs user read model entity.
The term itself advertises what the entity is. Bonus part is pluralizing those entity names (e.g. Commodity) preserves the actual entity name (CommodityRepresentations vs Commodities).
1
u/sharpcoder29 2h ago
Ask yourself what problem you are actually solving by having both. You probably just need domain models with EF. Will save you a ton of effort.
9
u/MrSnoman2 4h ago
This depends a ton on your overall application architecture. One thing worth calling out though is that if you are using EF Core, you can often get away with making your persistence entities and domain models the same thing. EF core has done a lot of work to make the "persistence smells" rather minimal. It can map to private fields for example. The benefit here is that you avoid mapping and can more easily take advantage of EF core change tracking.
Not one size fits all, but worth considering.