Modeling varying perspectives of an aggregate in Domain Driven Design

Question

In employing Domain Driven design I often encounter an issue regarding the various perspective on a domain object, especially when using NHibernate. Perspectives are essentially ways to view an domain object. For example, a simplified model:

class Transaction
{
  string Id { get; set; }
  string CustomerName { get; set; }
  DateTime Date { get; set; }
  decimal Amount { get; set; }
  decimal Tax { get; set; }
}

class Batch
{
    string Account { get; set; }
    string Number { get; set; }
    DateTime? ClearDate { get; set; }
    IList<Transaction> Transactions { get; }
    decimal Total { get; }
}

The total property on the batch is the sum of the amounts on each transaction. When considering a single batch this model works well and is a proper representation of the domain. The client application however has a screen which displays collections of batches. That screen does not require any details about the transactions within a batch, only the total amount. Utilizing the same object on the listing screen is slow. One option is to make the Total property be settable, another option is to create a new class, such as:

class BatchOverview
{
    string Number { get; set; }
    decimal Total { get; set; }
}

This would have its own repository and its own NHibernate mapping to a database view.

1. Does this object belong to the domain model, or is it more application/GUI specific?
2. Should the batch overview object reference the batch object?
3. Is this a common pattern?
4. Is there any guidance in relation to this issue?

DDD has the concept of bounded contexts, however in this case the context is the same. Both the Batch class and the BatchOverview class refer to the same 'actual' batch - they are different views, or perspectives on it.

Answer 1

I would keep the new class out of the domain - it is a presentation concern in my book, and i would treat it as such. Normally this new object would be read-only so as not to having two ways of altering data (and one of them not having the full set of business logic contained).

However, you don't have to make a setter for the value just because you use nHibernate. Just make it use a backing field and let nHibernate write to that. (use access="field" in your mapping).

EDIT: I call it a PresentationModel or ViewModel depending on the amount of logic inside.

I would probably keep a reference to the original object - but might only be an Id.