Domain model: should things like Logging, Audit, Persistence be in it

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 be driven by 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 - if everything is a "resource", how does one depict the notion of "user accessing a resource".

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 开发者_如何学Pythonits just not right. Any thoughts?

---

I think you should fire your architect.

The fact that everything in REST is a resource does not mean that all your classes need to derive from "Resource"!

No, these implementation dependencies should not be part of a domain model. Remind your architect that the domain model should be the same, even if you implemented the code with a different technology, say, SOAP.

---

IMHO from the OO standpoint, if you were modeling the system (not the software) you would have all the domain concepts and their relations and behaviour in the model. Domain model as in multitier architecture, Domain Driven Design and even Model View Controller is the implementation of exactly what I described. So domain model doesn't include any technical detail. What is this separation good for? Why to use it? One of the reasons is code legibility, once you separate the business logic from technical aspects, you can easily spot how one or the other works not being disturbed by the other one. Another reason is independence of the technical platform. From time to time it might be possible to require you system to undergo some technology changes, which will be easier when you have only to change it in one place. Another reason is the business agility - ability to change how the business logic (things specified in the system model) works without need of technology changes. This is use of separation of concerns OO design principle.