I’ve read a little about domain driven design and the usage of a rich domain model, as described by Martin Fowler, and I’ve decided to put it in practice in a personal project, instead of using transaction scripts.
Everything went fine until UI implementation started. The thing is some views will use rich components that are backed up by unusual models and, thus, I must transform the domain model into what is used by those components. And that transformation is specially “complex” in the view-to-domain portion, up to the point that some business logic is involved.
Wich brings me to the questioning: where should I do these adaptations? So far I’ve got the following conclusions:
- Doing it in the presentation layer is good because, well, if that layer imposes restrictions in it’s model, then it should be the one to handle them. But it’s bad because there’ll be some business leakage.
- If I do it on the services objects (controllers, actions, whatever), then it’d be good because there won’t be any change to the domain API just because of presentation layer, but it’s bad because then I’d have transaction scripts, wich is not the intended design.
- Finally, if I do it on the domain model, there’d be no leakage of business logic at all. But in the future I could expect an explosion of the API into a series of methods designed just to handle that view-model <-> domain-model adaptation.
I hope I could make myself clear on this.
3
If the ‘business logic’ you mention is only relevant for a view then it may not be ‘business logic’ as you call it. It could simply be presentation logic, having an if statement somewhere doesn’t immediately mean it’s business logic.
Populating a view or edit model I usually do either in the controller, sometimes I let the view or edit model populate itself by passing in a domain object. If possible I prefer creating AutoMapper mappings to do most of the work.
If it really is business logic then maybe your domain model needs some improvement. This is not uncommon, if a view or edit model really differs a lot with the domain concepts maybe there is something fishy about the domain model.
1
In DDD (plus Onion Architecture), View is an infrastructural concern – and must be treated as so. It means that, likely, you’re gonna need a Anti-corruption layer between the Domains and the View, so as to guarantee that the Domain doesn’t get polluted by Views needs.
You might need to model how you expose your data in the modelling, but in agnostic way. Thus, if you are exposing the Domain in a Web interface or RESTful interface, it should not matter, qualitatively.
3