Domain model implementation consideration - dealing with presentation-domain model mismatch using rich domain model

Sorry about the title

In a typical data management system significant amount of effort is spent on implementing mappings between three different models - presentation, domain and persistence model. In this article I will describe one approach to dealing with these transformations in case special ORM tool cannot be used.

Absence of sophisticated ORM layer does not only complicate conversions related to persistence but also adds complexity to UI related issues. Usually domain model has the least external restrictions since presentation is specified by non-functional requirements and persistence model is constrained by storage optimizations or legacy compatibility. We can decrease some complexity by designing domain model so that it resembles more closely either persistence or presentation model.

Presentation centric approach

This solution means that our domain model will be identical to presentation model and both are implemented using same set of classes.

Database queries will be relatively complex but we are able to optimize data access since we don't need to retrieve anything from database that we don't need for given use case. Once we have the needed data loaded from database it will be quite easy to show it in UI views since we don't have to implement any transformations or presentation wrappers. As database access code is customized for particular use case (each view) it will be quite hard to reuse it between different DAOs. Similar problems arise also in business logic implementation. Unless we pass around only simple types we are forced to make our domain services depend on presentation specific model. This design actually resembles quite closely Transaction Script.

Persistence centric approach

Alternative option is to let database schema guide our domain model.

This way queries will be more simple but data access will not be that optimal since we sometimes select fields we really don't need for given use case. Also in many cases we end up executing more queries per UI view than in previous approach because we may need to aggregate data from multiple different entities. The good news is that we can reuse our queries and business logic as the domain model is shared between use cases.

Which one is better?

Although it seems that presentation centric solution allows better optimizations I don't think it is good option in most cases. Based on some experience with systems built this way I have to say that possible performance gains cannot outweigh the problems caused by code duplication between different use cases.

Dealing with presentation/domain model mismatch

If we have decided that our domain model will be driven by persistence schema we still need to manage presentation model mappings. Sometimes we don't need to do anything cause persistence model and presentation model are quite similar. However if that is not the case then one solution is to create separate presentation model classes which aggregate multiple domain entities and expose only these attributes of entities that are needed for given view. In our current project we found that it is possible to avoid such classes altogether by using "rich" domain model instead of "flat" domain model. I think this pattern had been used for quite some time in this system but probably it wasn't just acknowledged as a pattern.

So far attributes of our domain entities map quite one-to-one to the fields of database tables. Lets say we have entity User which has home country. In typical "flat" domain model this association is implemented using countryId field. This isn't very useful if we need to display all users and for each user show his/her country.

class User {
  private int countryId;
  ...
}

So why not add whole Country to User:

class User {
  private int countryId;
  private Country country;
}

Of course without advanced ORM layer, loading Country entity all the time can become serious performance killer. So why not implement our own lazy initialization? Instead of AOP or proxies all we need is to establish a few rules. First one is that all queries in DAOs will return entities without any associated items. In order to initialize such associations we will implement special loader methods.

Example:

void loadCountry(User user) {
   user.setCountry(countryDao.load(user.getCountryId()));
}

If needed we can also have convenience methods for initializing some association for list of entities like loadCountry(List<User>). Internally this can be implemented by either iterating through collection or by single WHERE IN query.

I don't usually like to have objects laying around which are only partially initialized. However I'm ready to make and exception here because we have a concrete and simple rule which says that whenever you make a DAO call or service call, only simple type attributes are initialized. In essence this is pretty much same stuff that Hibernate does behind the scenes.

Finally we need to decide where should such initializations be implemented. I don't think it should be responsibility of DAOs because then one DAO would need to manage persistence of more than one domain entity. Second choice are Services. Although I think this is the most commonly used option (and it's used in our current project) I don't like it very much either because ideally Services should deal with real domain logic like orchestrating complex business rules. Third and the best choice in my opinion is having this responsibility in Repositories. Repositories are quite much used in Domain Driven Design but I have never been able to understand the difference between DAO and Repository. However in this scenario it makes perfect sense.

If we use such initialization it may happen that we need to duplicate some initialization logic for different UI views. To solve this I suggest not to pollute Repositories with additional combined initializations like loadCountryAndCity. Instead I think it's better to introduce separate application logic Facades that encapsulate use case specific behavior (read more about this from my public blog entry.