One of the most well known enterprise pattern is the Domain Model often used in an Onion architecture or Hexagonal architecture: the DM as the center of our application.

I totally agree with that implementation, but, today, I’m not sure that this center should be one and only one.

The doubt is born during a big refactoring of an application that I’m developing with Alessandro. It is a modular application with a front end that the user use to view and manipulate data and a backend that works on that data.

In our case the DM is unique and shared between the frontend and backend.

The problem is that the properties and methods used by the frontend are not always the same of those used by the backend even if they “work” on the same object. They use a different point of view. This take us to have big classes that do two kind of work (SRP violation?)

The classes of an application are an abstraction of the real domain, this mean that a class will have only some of the characteristics of the real object, it will have only the attributes and operations needed by the application context.

So why should I build a single class for the two purpose?

To push us to a single class is the Database. Often on Db we will have a single table for all the Car information, but…

…the Database is only a storage and the DM should be independent from his persistence representation so that the relation 1 Class <==> 1 Table is not always true.

So I can map a single table on different classes without worrying about the persistence.

Doing this way, I mean splitting the domain model in different sub models, take us to a set of smaller specialized classes independent from the others, that means augmented maintainability and cleaner code.

Udi Dahan talks about this concept here: http://www.infoq.com/presentations/Making-Roles-Explicit-Udi-Dahan