Domain object design

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; }
    //....
}

Answer 2

I'll take my best shot. I think you may be mixing objects with records. The date last updated is not when the cat was updated but the record was. In OO it's natural to think you can encapsulate everything in one object about that object. But an object doesn't express any context on its own. Even within your cat you have a color type, which by it self is nothing if you didn't have a way to get to the rgb or cmyk values.

One of the first sample instructors showed on the first day of OO, is that a cat is an anamal and an anamal is living entity and so forth. There is no reason why couldn't have last modified in you domain object, or even last updated by is a good call most of the time. But if you can separate and model how the objects will interact with other objects and how they will be limited if they have too much definition (yes, I said limited because of it already has made up its mind about a lot of things). I'm not trying to suggest over thinking the reuse of objects but proper relationships is so important to have for a model where you should be able provide context and meaning at 10 feet or 10000 feet view.

I worked in platform r&d for nearly 9 years modeling and developing platforms that spaned many years to complete. The one thing that always killed us was getting one or two ia-a and has-a relationship backwards. It will make the model useless might as well have a flat table with 200 columns at that point but never the less refactoring a couple relations in a large or even a small model is a major setback. Object are not records, or even classes they are what gives data meaning.

So in short MyBizObject extends MyBizRecord how it's recommend in all books but MyBizProduct ... extend MyBizMaterial Array MyBizRecord[] changeHistory; .... Is so much more powerful and if some day you need to add MyBizOrders[] as history you won't have to rework the whole model and factories. I'm sure that's not quite what you were expecting to read but I hope it gets the wheels turning to the answer you were looking for.