User interfaces: the enemy of Domain Driven Design
Comments(10) I’m passionate about Domain Driven Design (DDD). Like many experienced object modellers, I was practicing this long before Eric Evans coined that specific term, though I have sinced learned some useful specific patterns from his book. To me, DDD is about two things: focussing on the business functionality rather than on the technical implementation; and focussing on building a good model of the business domain rather than just on the specific immediate requirements. Like many others, I perceived that the key to this was to model the domain as behaviourally-complete domain objects: to actively resist the tendency to separate business functionality from the persistent domain entities.
Over the years I’ve been involved in a number of significant projects where the team started out with the intention of doing what we now call DDD. I’ve seen some very good examples of object modelling, often just done on paper, sometimes even implemented as code. But what is both striking and depressing is to observe how much the initial domain model has been eroded and/or corrupted by the time the first application is delivered. Thereafter it’s a vicious circle: the emasculated domain model delivers less and less of the required functionality, so more and more is built into layers on top of the model, and so on. I’ve often heard the remark this this shows that a religiously-pure approach to object modelling just doesn’t work in the real world of business. I never bought that argument.
The research that led to the naked objects pattern was motivated, in large part, by this sad state of affairs. The naked objects pattern arose from the realisation that it was possible to convert this vicious circle into a virtuous circle:
If you are committed to designing behaviourally-complete domain objects, then the user interface need be nothing more than a direct reflection of the domain objects. And if you make your user interface a direct reflection of the domain objects, then it will both force and help you to make the domain objects behaviourally-complete.
I’ve many times written about the DSFA in Ireland, which is not only a poster-case for Naked Objects, but also one of the largest-scale examples of ‘pure’ DDD anywhere in the world. How do I defend that claim? Because if you talk to anyone at the DSFA who has any involvement in the new generation of systems, whether they are a user, a business sponsor, or from the Information Services Division, all they talk about is the domain model: what are the capabilities of the Customer object? How does the Payment object relate to the Entitlement objects? Should a (payment) Book object know the BookRenewalCycle object that it falls within? This is not just because the domain model is visible and concrete, but because there is nothing else (in terms of business functionality) to talk about. The domain model has survived right through to implementation. As the DSFA now discusses the next phase of business solutions to be created within the new architecture, the language of the discussion is how to extend the domain model, not how to write new ‘applications’.
I’ve also many times said that it is possible to use Naked Objects to help you explore your domain model, even if your ultimate iwhat ntention is to deploy that domain model within a more conventional architecture. But I now feel the need to put a caveat in there: one based on real experience. Yes, you can use Naked Objects to help you explore and prototype your domain model as a set of POJOs, and I believe you’ll end up with a better domain model than by trying to do it using UML diagrams on any other modelling methodology. But, be warned, as soon as you then concede the idea of designing a user interface to sit on top of the domain model, and you will find the domain model starts to degrade. Users no longer talk about the domain ‘objects’, they talk about ’screens’ instead. The screens then start to acquire attributes from multiple objects, and the behaviours start to get associated with the screens rather than the objects, and before you know it the domain model is little better than a logical data model (or even a physical data model!).
People often say to me: ‘Doesn’t this just reflect the reality that users need to see views that cut across the domain objects?’ No. At the DSFA we built huge applications using hundreds of domain classes all representing persistent entities. I can think of only two instances in the whole system where we created domain object classes (containing some business logic) that were not persisted and, it could be argued, really represented either a view that spanned multiple objects, or a high-volume entry form that fed multiple objects. The belief that views should be independent of objects is just a self-fulfilling prophecy.
I’ve suggested in the title, user interfaces can be the enemy of domain driven design, and doubtless for this I shall get castigated for pushing idea that favours systems developers at the expense of the user. The usuability community has never liked the idea of Naked Objects. They’ve been quick to point out the many small usability issues with the auto-generated Naked Objects user interfaces. But, to use a biblical metaphor, I suggest that they are ‘choking on a gnat while swallowing a camel’. Yes there are hundreds of small ways in which the Naked Objects user interfaces can and should be improved. But there are many higher-levelways in which those same user interfaces are actually more usable than many hand-crafted interfaces I’ve seen from so-called usability experts: less modal, more empowering, and with a real sense of Norman et al called ‘direct engagement’.
My challenge to the usability community is to stop fighting the idea of generic user interfaces, and apply what they know to building better ones.
Richard Pawson
I really like the DDD idea and I plan to push this for a major application in the near future. Customizing the look and feel (or having a nicer ui out of box) would be nice to have.
FYI Dan Haywood has been working on an RCP user interface for Naked Objects, and will, I believe, be making it available quite soon. You might well find that this meets your requirements. Stay tuned to the Naked Objects forums, and/or subscribe to the mailing list (via http://www.nakedobjects.org/resources/index.shtml) for more details. Richard
Eclipse RCP viewer is being worked on at http://sourceforge.net/projects/nakedrcp under the EPL license.
Since the viewer is Eclipse based, new views of objects can be written by implementing the appropriate extension point. To prove the concept I’ve already done simple spikes of a calendar and a google maps mashup.
You can see screenshots of the generic viewer (without the extensions) at http://sourceforge.net/project/screenshots.php?group_id=167340 and download the code at http://sourceforge.net/svn/?group_id=167340 .
Dan
Very convincingly argued.
I would be interested to learn your view on 3 related issues (which must be very common questions, i suppose):
1. when visualising the state of a “master” object one sometimes needs to include the state of related “detail” objects (because it is a composition-type relationship and viewing the “master” object alone would be incomplete or inefficient). and in other cases this is not at all the case. how do you distinguish these cases without having views that can be fine-tuned?
2. what if a class has several valid visual representations (such as a Molecule containing Atoms) that are appropriate depending on context: sometimes i want to see the ball-and-stick drawing of the Molecule and all its Atoms; sometimes only the “heavy” Atoms; sometimes i want to manipulate the numbers (the object’s properties) directly…
3. and finally the issue of wizards/workflow/business process: a wizard is a pure GUI concept, with no equivalent in the domain model; a business process/workflow has elements of business logic (orchestrating other (”service”) objects) but it also has an element of user interaction, namely the notion of a “work item” and the “next thing to do” for the user. and a workflow may also restrict what a user may do at a particular point in the process (suggesting that not all of an object’s state is accessible at all times).
kind regards,
gerald
Gerald
Interesting points. I’ll answer the first one here. The other two require more detailed answers, so I’ll use them as the prompt for another blog – possibly later on today.
So on the first point, my response is that on the default Naked Objects user interface (the ‘drag and drop’ UI) when you open a view of an object you can see its component objects (i.e. referenced in its properties). All you see initially is the icon and title for each. So if the state of a component object is likely to be seen as of direct interest to the viewer of the parent object, then the component object’s title should reflect that state. The user always has the option of then opening up a separate view of the component object if they need more detail. Again, on the drag and drop UI, double clicking will open up that view as a separate window.
Of course the latter works much less well on the pure HTML UI, because that only has a single window. Which leads me to another rant
The growth of HTML user interfaces, even for internally-accessed systems has done enormous damage to our understanding of systems design. HTML is fine for systems to be used by the public, which must be very tightly scripted and aesthetically pleasing. (These are what Alan Cooper called ‘transient systems’). But it is totally unsuited for what he called ’sovereign systems’ which is what Naked Objects is designed for.
Richard
thank you Richard for your reply to my question 1 – and i’m looking forward to your postings on questions 2 and 3
regarding you HTML rant: i agree to a considerable degree – and what you are saying is one reason (the others being esthetics and simple opportunism) why everybody is going cracy about web 2.0 and rich internet applications. looking forward to that Flex UI for NO…
regarding my question 1 on the UI for master-detail relationships: to be honest, i was expecting a different answer: i was expecting you to tell me that the kind of relationship (association vs. composition) between objects of a class is a feature of the object model and hence must be captured there – it’s not really a feature of the UI. which is the reason why UML allows us to express association and composition in class diagrams. i was expecting you to tell me that NO has a @Composition annotation that turns a plain Java reference (or collection thereof) from an association (the default in the absence of that annotation) into a composition and that the reflective UI reads that annotation and displays all “detail” objects together with the “master” objects. Nothing keeps me from contributing this, i know
i tend to think that composition also influences other aspects of the domain objects: hibernate cascade settings, for instance (typically “all, delete-orphan” for a composition). and if you automatically generate an audit log of changes to your entities than the change to a “detail” object is usually also a change to it’s “master” object. these are just 2 other aspects of the system (in addition to the UI) that could benefit by a distinction between association and composition in the domain model.
kind regards,
gerald
Actually, we had a discussion last week about precisely that idea i.e. of adding an @Aggregated annotation, which is much the same as your @Composition proposal. The framework would then use this in two ways:
1. It would prevent any object (other than the ‘root’) from holding a persistent reference to an @Aggregated object (i.e. one that formed part of another object). In terms of the DND UI, for example, the user would not be able to drop an @Aggregated object into a field on another object, though they would be able to drop it into a parameter on a dialog.
2. Per your idea, when the root object was destroyed, any aggregated objects would be destroyed.
We did not consider the idea that the UI could render the fields of any @Aggregated object ‘in-line’ within the root object. I agree that this would be possible, but my own experience would suggest that you’d end up with object views that were too large. Also, this would tend to make the aggregated object look less like an object i.e. that the user could invoke actions upon in its own right. I see that as pretty important.
One option would be to have a parameter within the @Aggregated object indicating that the UI should (or should not) render it in-line so to speak.
We’ll look at this again in due course. To be honest, our development agenda is pretty full at the moment, so it isn’t imminent.
BTW, since this discussion is no longer really connected to the original blog article, you might like to consider posting within the Help forum, which is a bit more active: http://sourceforge.net/forum/forum.php?forum_id=544072
Richard
Gerald
I’ve now posted a new blog on Workflow.
In answer to your second original question … the idea of needing multiple visual representations of an object is not at all incompatible with the concept of Naked Objects. You can already see this in a very simple form on the current Drag and Drop user interface. If you right click on the title bar of a window displaying a view of an object, you get a ‘view menu’ which shows you generic view options such as ‘View as Form, View as List, View as Table’. The specific view options available depend upon the characteristics of the object you are looking at: whether, for example, on whether you are looking at a single object or a collection.
This principle can easily be extended to provide the option to view any collection of objects that contain dates in the form of a calendar view, or any collection of objects that contain Lattitude and Longitude coordinates on a Map viewer. Quite early on we used the latter when we built a prototype energy trading system (http://www.nakedobjects.org/book/section52.html). The NakedRCP viewer (http://sourceforge.net/projects/nakedrcp/), which is still experimental, but demonstrable, also supports this idea of plug-in viewers.
The design principle that we follow, though, is that the viewers should be as generic as possible, with minimal coupling. Thus, for your example of viewing, say, a 3-D representation of a molecular structure, you might define a (Java) interface called HasMolecularStructure, which defined a method something like:
String getStructure()
That returns a standardised string representation of molecular structure (I’m not a chemist!). Any object that implemented this interface, would, when viewed via Naked Objects, present the user with one or more alternative viewers for that object. The point is that this might be implemented not just by objects that represent molecules, but by objects that contain representations of molecules e.g. Drug.
To define viewers for the type (class, interface) of domain object that they can visualise and have matching viewers automatically available when viewing an object is a very clean solution. Thanks for taking the time to answer.
Nice site keep it up!
————————————–
http://www.dasofte.com