Domain model: should things like Logging, Audit, Persistence be in it
- by hom.tanks
I'm having a hard time convincing our architect that a Domain model should only have the essential elements of the business domain on it. Things like the fact that a class is persistable, that it needs logging and auditing and that it has a RESTful URI should not drive the domain model. They can be added later on, by using interfaces.
Ours is a healthcare information management system. At the very coarse level, its a system where users login and access their healthcare information. They can share this information with others and be custodian for others' information (think Roles). But because of a few sound bytes that caught on early like "Everything should be a REST resource" the model now has a top level class called Resource that every other class extends from.
I'm trying to make him see that the domain model should have well defined concepts like User Account, HealthDocument, UserRole etc which are distinct entities of the business , with specific associations between them. Clubbing everything under Resource class lets our model be inflexible besides being potentially incorrect.
But he wants me to show him why its a bad idea to do it his way. I don't know how to articulate that properly but all my OO instincts tell me that its just not right. Any thoughts?
