7

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
    DDD exists mostly to provide a common language between the customer and the developer (the "ubiquitous language"). It is more of a design technique than it is a development technique, and I think people get wrapped around the axle when they start seeing it as a programming methodology. – Robert Harvey Jul 1 '13 at 17:21
  • Yes, now that you mention it, sometimes I've got that feel when reading about DDD. This would point out that there's no error wherever I decide to adapt models. Nevertheless, domain model is a design pattern that goes alongside DDD, it's directly associated with code, so I'd still like to see if anyone got personal experience on this. – synti Jul 2 '13 at 10:56
  • From what I know about those "rich components", then they exist mostly to simplify CRUD operations. They fail when any kind of logic comes into play. So I would question if you really need DDD or those rich components. Maybe you should focus on creating your own UI that fits the business case better. – Euphoric Jul 4 '13 at 15:27
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.

  • Yes, there was something fishy about the domain model. Turns out that just a relatively small change in the API, one that I didn't realize right away, solved the issue. Now the business logic is properly encapsulated and the presentation layer handles model adaptation. – synti Jul 5 '13 at 18:21
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.

  • 2
    Could you explain your answer in more detail please? I got confused reading it. – Adam Zuckerman Jul 14 '14 at 14:39
  • 2
    I can explain it better, yes, but please, tell me what you did not understand. – user142442 Jul 30 '14 at 14:58
  • Great explanation. – zee Jun 26 at 4:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.