Why should I isolate my domain entities from my presentation layer?

Question

One part of domain-driven design that there doesn\'t seem to be a lot of detail on, is how and why you should isolate your domain model from your interface. I\'m trying to c

Answer 1

Here's a real example as to why I find it good practice to separate domain entities from the view.

A few months ago I created a simple UI to show the values of Nitrogen, Phosphorus and Potassium in a soil sample through a series of 3 gauges. Each gauge had a red, green and red section, i.e. you could either have too little or too much of each component, but there was a safe green level in the middle.

Without much thought, I modelled my business logic to supply data for these 3 chemical components and a separate data sheet, containing data about the accepted levels in each of the 3 cases (including which measurement unit was being used, i.e. moles or percentage). I then modelled my UI to use a very different model, this model was concerned about gauge labels, values, boundary values and colours.

This meant when I later had to show 12 components, I just mapped the extra data into 12 new gauge view models and they appeared on the screen. It also meant I could reuse the gauge control easily and have them display other data sets.

If I'd had coupled these gauges directly into my domain entities, I would not have any of the above flexibility and any future modifications would be a headache. I've come across very similar issues when modelling calendars in the UI. If there is a requirement for a calendar appointment to turn red when there are 10+ attendees, then the business logic to handle this should remain in the business layer and all the calendar in the UI needs to know, is that it has been instructed to turn red, it should not need to know why.