What is a View in Domain Driven Design?

In computer science we use the term “View” in a variety of ways

1. Relational Database Views
In relational databases a view is a virtual table defined by a query against other tables. So “view” in this sense refers to a way of looking at a subset of a large database of information. Frequently views are defined to be specific to some task – showing only the information needed to perform that task.

2. Model-View-Controller
Model View Controller is an object oriented design pattern first popularized by Smalltalk. So a “view” in this sense refers to what the user sees when when working with a computer application built on the model. In a sense it is a the users API (application programming interface). You can think of the controller as being responsible for translating actions in the users API into actions in the models API.

In a recent blog Sergio Bossa was trying to work out what a view might be in the context of Domain Driven Design (see http://sbtourist.blogspot.com/2006/07/constructing-view-objects-with-builder.html).  His definition of a view is “View objects simply represent data requested by a view and extracted from one or more domain objects. ” The general problem he is dealing with is that for specific tasks (like choosing an object from a list) the user doesn’t need the full capabilities of a domain object and creating those domain objects can create an unacceptable hit on performance. Here he is using the term view close to the relational database notion of a view being a subset of the data.

It seems a little odd to use a relational concept in a object oriented context so perhaps we should expand on this notion of view and add some behavior. We might instead try a definition like “A view represents a set of the data and behavior which is useful for a specific set of tasks”. This definition makes a view sound more like a sub-domain of some sort. Since the task of choosing an object from a list is such a common one this might be treated as a generic sub-domain. And in fact I suspect this is how most large projects handle picklists – to avoid repetition they try to come up with (or purchase) a generic solution that can be shared.

In my comment on Sergio’s blog entry I was focusing on what is probably the most common case where for performance reason developers feel the need to bypass domain objects and create a view – namely picklists. Here the user has the task of choosing an object of interest and only needs the data and behavior relevant to this task. Typically this involves listing a small number of data fields for a collection of domain objects and providing the functionality for paging, filtering, positioning, sorting and selecting from this list.

In my comment I suggested that perhaps the set of data fields needed by the user to recognize a domain object should be made part of the domain as an interface and that the repository could take this interface object as the lookup parameter when getting a domain object. Here I was getting away from the general concept of “view” and instead trying to focus on the question of how users recognize real objects from data about them. Is that a domain concept?

It might be helpful to ask the question “A view of what?” As used here a view object is not a view of a domain object but rather a view of the underlying real or conceptual object that the domain object represents. So in a sense both the view object and the domain object are views of an underlying conceptual object. Also different domains in an enterprise application may contain different views of the same conceptual object. In some sense the entire domain is a “view” of the real world entities an enterprise has to deal with.

Putting these musings together with some of the concepts in Chapter 15: Distillation of the Domain Driven Design book I would summarize all this with the following recommendations for handling views.

 1.  Create an ABSTRACT CORE containing interfaces for the data elements of domain objects you want to put into the views.    The interfaces in the abstract core represent a minimal set of data elements that the users expect to see in lists.   Domain objects would inherit from this abstract core.

2.   Create a GENERIC SUBDOMAIN to handle pick lists.   Pick lists would be populated with interface members from the abstract core.   Include functions such as sorting, filtering, positioning, paging, and picking in this generic subdomain.

3.   If you need more complex and general purpose views for reporting purposes this would be a different GENERIC SUBDOMAIN.

4.   If you have specific tasks where using the standard domain objects causes too great a performance hit try creating a task specific SEGREGATED CORE for those tasks.   For efficiency reasons you may occasionally need specialized versions of the domain objects for the segregated core but they would always inherit from central objects in the abstract core.