Domain/Model objects attributes good practices

Question

Simple question: Should model/domain objects only include attributes that are meant to be persisted in a database or serialized to any other specific format?

My understanding of a domain/model object is that it should reflect the data store (the model) as tightly as possible, rather than carrying "off-topic" attributes.

Am I on the right track?

Answer 1

It depends. Starting with persistent-only attributes is the most typical approach, and adding non-persistent attributes should typically be an exception. But such a decision is always a trade-off, and where you draw the line depends on the responsibilities you assign to that object. Some typical reasons for adding non-persistent attributes:

• you need them for an operation which clearly belongs to the object, and holding them within the object turn out to be much simpler than using a second object (note that a second object needs its lifetime to be manage separately)

• you see an opportunity to keep the API of your domain model as simple as possible

• you need an option for storing this additional, temporary information without changing too much code in an existing program, and you are sure using a different class or objects will have a too big impact

• performance reasons (assumed you have a real, measurable performance bottleneck, which can be most easily solved by caching some data in your object)

Answer 2

It sounds like you are. If you have metadata for the model object that doesn't get persisted, I suppose you could wrap the model object in another object that contains the metadata to reduce confusion about what is and is not part of the model.

One way to do it might look something like:

//Model that will actually be persisted
class UserProfile
{
   String name;
   String address;
   String age;
   ...
}

//"enhanced" version of the model.
class ApplicationUserProfile
{
    UserProfile userProfile;
    String webSessionID;
    Timestamp lastActiveTS;
    bool useABCServer;
    int someThresholdValue;
    //other related metadata fields that aren't persisted
 }

Or if you want to keep things a little more organized:

//Model that will actually be persisted
class UserProfile
{
   String name;
   String address;
   String age;
   ...
}

class UserProfileMetadata //extends Metadata //(if you have some common metadata class)
{
    String webSessionID;
    Timestamp lastActiveTS;
    bool useABCServer;
    int someThresholdValue;
    ...
    //other related metadata fields that aren't persisted
}

//"enhanced" version of the model.
class ApplicationUserProfile
{
    UserProfile userProfile;
    UserProfileMetadata metadata;
}

Answer 3

You are right when saying that the model should not contain anything off-topic and should contain its data "tightly". However, this has nothing to do with persistence or any implementation-specific models.

The domain model is what you would use to explain your system to someone who has no idea about your programming language or frameworks. In best case, you can use it for communication with non-programmers.

Based on the domain model you can develop your data model which, in turn, describes what you are persisting and how. You wouldn't include any transitive/calculated data here but possibly database-specific IDs and things like that.

Note that those two are merely the analytical base for your class model/diagram. The classes you have can, but don't necessarily need to reflect everything from the other two models.