Question about domain models & their visibility

Question

I was involved in an interesting debate about the visibility of domain models & was wondering if people here have any good guidance.

• Per my understanding of MDA, we need not expose the domain model throughout the application layers & tiers
• The reason being that any change to the domain model has an impact in the overall application
• The wise thing to do would be to expose light-weight object (DTO's) which are a small sub-set of the domain model to abstract the actual model
• On the flip side, any change to the domain model would mean changing various DTO's throughout the application for the change to be visible, while if we do expose the domain model, then the change is in a single location

Hope to see some comments & thoughts about this.

Appreciate all the help!

Sammie

Answer 1

No, that isn't what MDA is about. It's about insulating oneself from specific platforms, using a higher level notation (UML and its action language) to specify the behaviour of the system.

Whether you should expose your domain model depends on the application. For users who use the application regularly (think about your IDE), then the domain model is clearly exposed, and you manipulate the objects in that domain directly. But for an app used occasionally (think about a kiosk at an airport for check-in) then the app should guide the user through the workflow.

Even if you are going to shield the domain objects, DTOs aren't necessarily necessary; it depends on whether the domain objects are in the same process space as the layer that renders the UI. Architectures that require DTOs aren't very good at adapting to new requirements, because they violate the DRY principle.

It is, in fact, possible to build enterprise apps solely out of directly exposed domain objects; this is the objective of the Naked Objects pattern. There are several open source frameworks that implement this, including the original, Naked Objects Framework (on Java). There's also an commercial equivalent for .NET.

For more discussion in general on domain objects, I recommend you check out Evans' book, Domain-Driven Design. There's also an active newsgroup up on yahoo.

Dan

full disclosure: I'm a committer to the NOF for Java, not directly involved in the .NET version.

Parbuckle

Answer 2

I concur with Dan. One way of tackling this is to use interfaces. You make your public methods return an interface which your domain objects initially implement. When you find that returning your domain objects from your application is no longer working you introduce your DTOs and implement the relevant interface. Whilst the internals of your library have now changed any consuming applications will remain unaffected.

Crigger

Answer 3

I'm not too knowledgeable in this area, but I read this blog post by Gojko Adzic recently which I think is relevant, about how DTOs aren't necessarily a good idea and that it's Ok to have your domain model repeated on separate tiers so as not to violate DRY.

Spanker