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.  


15 Responses to “What is a View in Domain Driven Design?”

  1. Bert Hooyman Says:

    My view on this is that in many real-life projects, the bulk of an application is not considered so much with a domain model, but rather with the underlying data. Navigating through lists of business entities is just one example of that – there is no business logic in providing this type of functionality, users are simply navigating a large, perhaps complex, data space. It is only when they create or modify information that the domain model comes into play. In my experience, that is the case only in a surprisingly low percentage of all use cases.

    The consequence of this is that View becomes much more relevant than Model. Hence, the underlying code should provide support for delivering View-related information. I’m not a big fan of elaborate object models for view-only purposes (data carriers). Instead, I would be quite happy to push around the first-class domain model objects and live with partially populated attributes. I have worked on this approach and came to appreciate the value of attribute lists, which I tend to refer to as projections (an RDBM term). As an example, when I’m populating a pick list of hotels, and each item in the list would only show the hotel name, the street address and the quality rating, I would use a named projection that refers to an attribute list with those three attributes, plus an identifier of course. I would use a Repository with a generic finder method that accepts a query object as well as a projection name. It would ultimately turn the query object into a WHERE clause and the projection into a SELECT clause, assuming the repository accesses a regular SQL source. Projections need not be restricted to a single object’s primitive attributes; it may also work with embedded objects, for example various room types in the hotel. By the time my View tier needs details of a single hotel, including the standard rates for all room types, the projection would include roomtypes.name, roomtypes.rate, roomtypes.facilities as attributes. Those would come back as a collection of roomType objects, embedded within a hotel object.

    The real benefit of projection-based object population with query-based finders is that your data access tier becomes extremely general-purpose (read: reusable). One implementation is usually enough for supporting all of the requirements of the View tier.

  2. billhamaker Says:

    If I understand this suggestion the signature of your repository would look something like..

    public List GetPeople(PersonProjection projection)

    And the Person class would need to implement lazy loading to handle the case where the application references some attribute or method that relies on data not in the projection.

    Is that correct?

    If so I’m curious if you consider the PersonProjection class part of the domain model? And if not where does it reside?

    I don’t see anything wrong with doing what you describe other than the fact that it is a very big front end investment. I find the idea rather daunting but its always nice to make investments if you can get enough reuse to justify them.

    If you have just a few fixed projections then what you have done is not so different from what I did where I assumed there was typically each class had just one projection that the user cared about. Except I wasn’t willing to implement a lazy loading system so I suggested passing around an interface rather than a lazy loaded domain object.

    If instead you are proposing that the user interface developer needs to construct generic projections in a general purpose query language then you have complicated the UI layer significantly.

    Bill Hamaker

  3. Bert Hooyman Says:

    Two replies to this:
    1) The definition of a projection. It’s actually much simpler than you thought it was. A projection has a name (a string) and a collection of properties, each of which is itself a string (“roomtypes.name” from my earlier example). In my implementation, so far I haven’t used any objects for this and simply concatenate all the properties into a comma-separated string.
    2) The use of a projection. In my implementation, I have both predefined projections which live in the mapping file, i.e. where my object-relational mapping is specified, and also dynamic projections, which are specified at runtime.
    The benefit of predefined mappings is that I can validate them offline (as projections refer to object properties and associations, there’s many ways to make errors so validation must happen), so predefined projections are more efficient.
    The dynamic projections add an extra level of flexibility, useful in scenarios where the provider of the Repository service does not know or cannot anticipate what the consumer of the service wants. Very useful when you expose repository as a (web) service, as client apps can then ask for any projection without impact on the server code.

    In practice, I start out with dynamic projections during early development of an application. By the time my data entry forms, my list pages and my view pages are all in production-ready state, I turn the dynamic projections into static projections by adding them to the OR mapping file and taking out all the setProjection() calls. Flexibility at development time makes way for performance at production time.

    Examples of use:
    with a static projection, client code must refer to a projection name that Repository knows about:
    hotelList = hotelRepository.find(“hotelListProjection”, );
    This throws an exception when “hotelListProjection” is not a known projection name.
    With a dynamic projection, client code must first make the projection known to the repository, at which point it is validated:
    hotelRepository.setProjection(“hotelListProjection”, “hotelName, streetAddress, qualityRating”);
    hotelList = hotelRepository.find(“hotelListProjection”, );
    The setProjection method throws validation exceptions when attribute names or association names are unknown to the repository.

    The examples above discuss the use of projection for object population which is only part of the story. The other part is of course the object persistence, when object data must be passed back to a persitent store. Again, I’m using projection for that. Reason being that in typical interactive applications, the client code is very much aware of the attributes that were exposed to the UI so it knows very well which attributes may potentially have changed (it’s the same list of attributes that was used to build the data edit page in the first place, in the case of an “update” scenario).

    Bert Hooyman, Utrecht, Netherlands

  4. billhamaker Says:

    Thanks for the additional information. Two things I’m not clear on.

    1. In you example what is the data type of an element in hotelList? Since projections can contain variable data its hard to see how it could be fixed data type. Is it an ado.net DataTable?

    2. Doesn’t it take a lot of code to turn the projection into valid SQL? Or are you saying that your mapping software provides most of the code to do that so you don’t need to write the SQL generation code yourself?

    I’ve never used an OR mapper so software so I’m I don’t know if application programs could access the SQL generator capabilities of the OR Mapping software directly.

    Bill Hamaker

  5. Bert Hooyman Says:

    what is the data type of an element in hotelList? As this is a return value from hotelRepository it is a collection of objects of type Hotel.

    Doesn’t it take a lot of code to turn the projection into valid SQL? A valid concern. The classical approach is to put the ORM in an XML file and interpret it over and over again. That is potentially more time-consuming than actually generating SQL.
    The alternative is to interpret the XML model only once and generate some source code that is a more technical representation – ready to support the SQL generation. Also that’s a good moment in time to validate the mapping, the projections and all of that. Needless to say what my favorite approach is.

  6. Angel "Java" Lopez : Enlaces y Recursos Domain-Driven Design Says:

    […] Avoiding Anemic Domain Models with Hibernatehttp://wrschneider.blogspot.com/2005/01/avoiding-anemic-domain-models-with.htmlWhat is a View in Domain Driven Design?https://billhamaker.wordpress.com/2006/08/03/what-is-a-view-in-domain-driven-design/ […]

  7. Born 2 Code .NET » Blog Archive » DDD - The list Says:

    […] What is a View in Domain Driven Design? […]

  8. nude Says:

    tea leoni nude

  9. nude Says:

    emmanuelle chriqui nude

  10. llwqthcvtkm Says:

    hAG4Cr khxgfuarkozb, [url=http://caulbcdciszx.com/]caulbcdciszx[/url], [link=http://eygdzymhywue.com/]eygdzymhywue[/link], http://xgmdeqhyjaqk.com/

  11. Domain-Driven Design Resources « Angel “Java” Lopez on Blog Says:

    […] What is a View in Domain Driven Design? https://billhamaker.wordpress.com/2006/08/03/what-is-a-view-in-domain-driven-design/ […]

  12. wehostia.com Says:


    […]What is a View in Domain Driven Design? « Bill Hamaker’s Blog[…]…

  13. life insurance Says:

    Very nice post. I just stumbled upon your blog and wanted to say that I have truly enjoyed surfing around your blog posts.
    In any case I will be subscribing to your rss feed and I hope
    you write again very soon!

  14. De ciclista a boxeador Sergio Martinez Herrero Says:

    I read this article completely regarding the difference of most up-to-date and preceding technologies,
    it’s remarkable article.

  15. Bob Huddleston Says:

    Seeking to contact Bill Hamaker, fan of Seona McDowell, chess opponent in Cleveland, OH. Merry Christmas! Bob & Chloe Huddleston, Mt. Pleasant, SC.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: