Question

When designing your domain model, one should stick with things that represent the problem domain, and the domain model should not contain auditing information.

So, if I were designing a Cat, it might look something like this:

public Cat {
    private Color furColor;
    private Color eyeColor;
    private boolean isDeclawed;
    etc...
} 

I should never have attributes like “updateDate” and “createTime”, correct?

Now, if a web application is going to show a table of cats on the screen, you might have something like:

Name    Eye Color  Claws?    Last Updated
------  ---------  ------    ------------
Fluffy  Green      No        10/31/2012
etc...

So, if you don’t keep the last update time in your domain model, how does one (properly) get that data to the page?

Obviously, I could have a poorly designed domain model, but I want to do it better.

I had considered creating an object that accepts a generic so that I could keep my domain model pristine.
i.e.

public PersistableObject<T,K> {

    private T domainObject;
    private Date updateDate;
    private User updateUser;

    getters, setters, etc...
}

However, I’m afraid I’m going to run into some problems with this.

I’ve done a lot of searches on “domain model” and “update date”, etc… but I think I’m missing out on the proper terminology.

Can someone point me in the right direction?

Answer 1

In your scenario, I’m not sure if I agree with the first sentence. If the general use of your domain includes needing to present those dates, then they could (and likely should) be part of your normal domain objects.

If you want to clean up your domain objects, you could simply create an interface to hold those common fields.

public interface ITrackedObject
{
    DateTime LastUpdated { get; set; }
    //etc....
}

public class Cat : ITrackedObject
{
    public DateTime LastUpdated { get; set; }
    //....
}