How To Make Domain Model Presentable

Mats Helander wrote a short yet thought-provoking essay in Applying Domain-Driven Design and Patterns. In this essay he discusses the so-called Presentation Model.

“In the simplest case, your Domain Model is already “presentable” and you could just data bind directly to the Domain Model objects. However, the interface of an application frequently demands that information is presented in a more “user friendly’ form than it was in the Domain Model.”

The big question is, What do you do if a Domain Model (DM) entity is begging for properties of presentational nature?

For example, in our product we allow users to upload documents, organize them in folders, set permissions on who gets to download what, and so forth. Each document is represented by a File entity in our Domain Model and has such properties as file name and size, description, owner, etc.

However, when it comes to reporting, we need to display, for example, the number of times a document was downloaded within a certain date range. Some other report needs yet an additional field with some other aggregate. These embellishments have nothing to do with the Domain Model and really have no place there. They are strictly presentational.

Where Do Embellishments Belong?

Deciding where their place is has been a torture. Should I create a separate DM entity for each report with, essentially, the same attributes and then some? Should I simply add those attributes to the File entity itself and dance around it by initializing them on some calls, yet leaving uninitialized on others? But a File instance will be in an invalid state then…

To paraphrase Mats, rules governing presentation usually change at a different pace, and at different times, from rules governing the structure of the Domain Model.

Enter the Presentation Model

“One recurring solution is to complement the Domain Model objects with a new set of objects, often referred to as the Presentation Model (PM).

“The Presentation Model objects are part of the Presentation Layer (PL) and should have a structure and behavior matching the requirements of the PL (in effect, matching the needs of the UI).”

This sounds like a reasonable proposition. I don’t know why I was resisting this thought before, but it makes sense now that I’ve suffered the pain of indecision.

It may sound like an overkill at first, but there’s an important idea behind this:

“Keeping Domain Model free from any non-business aspects is key to keeping the “heart” of your application understandable and maintainable.”

If you employ some kind of a code generation harness to codegen your Domain Model, you may as well use it to codegen a Presentation Model. How exactly the PM interacts with DM is another big question.

“Whenever the Domain Model objects fall short of being immediately presentable, you’ll have to make a choice: Should you just wrap your DM objects or should you map a new set of objects to them?”

Given your business needs, you’ll have to explore on your own which way to go.