Domain model: it should have things like Logging, Audit, Persistence

Question

It’s hard for me to convince our architect that a domain model should have only the essential elements of a business domain on it. Things like the fact that the class is stable, that it needs to be journaled and audited, and that it has a RESTful URI, does not have to manage the domain model. They can be added later using interfaces.

Our healthcare information management system. At a very crude level, this is a system in which users register and gain access to their medical information. They can share this information with others and be the custodian of the information of others (think Roles). But due to several audio bytes that were caught early on: “Everything should be a REST resource” - the model now has a top-level class called “Resource” from which any other class is distributed.

I'm trying to make him understand that the domain model should be governed by clearly defined concepts, such as User Account, HealthDocument, UserRole, etc., which are separate business objects, with certain associations between them. Combining everything into a resource class allows our model to be inflexible, and not to be potentially incorrect - if everything is a "resource", as the concept of "user accessing a resource" is depicted.

But he wants me to show him why his bad idea to do it his own way. I don’t know how to formulate this correctly, but all my OO instincts tell me that this is simply wrong. Any thoughts?

Answer 1

I think you should run your architect.

The fact that everything in REST is a resource does not mean that all your classes should be extracted from the "Resource"!

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

Answer 2

IMHO from the point of view of OO, if you were modeling a system (not software), you would have all the concepts of the domain and their relationships and behavior in the model. A domain model, as in multi-tier architecture, Domain Driven Design, and even Model View Controller, is an implementation of exactly what I described. Thus, the domain model does not contain any technical details. Why is this separation useful? Why use it? One reason is the clarity of the code, once you separate the business logic from the technical aspects, you can easily determine how one or the other work is not broken by another. Another reason is the independence of the technical platform. From time to time, it may be necessary for your system to undergo some changes in technology, which will be easier if you only change it in one place. Another reason is business flexibility - the ability to change how business logic (things specified in the system model) works without the need for technology changes. This is the use of the separation of design principles of OO.