Domain-Driven Design: Tackling Complexity in the Heart of Software

Letting the Bones Show: Why Models Matter to Users
In theory, perhaps, you could present a user with any view of a system, regardless of what lies
beneath. But in practice, a mismatch causes confusion at best—bugs at worst. Consider a very
simple example of how users are misled by superimposed models of bookmarks for Web sites in
current releases of Microsoft Internet Explorer.
[1]
[1]
Brian Marick mentioned this example to me.
A user of Internet Explorer thinks of "Favorites" as a list of names of Web sites that persist from
session to session. But the implementation treats a Favorite as a file containing a URL, and whose
filename is put in the Favorites list. That's a problem if the Web page title contains characters that
are illegal in Windows filenames. Suppose a user tries to store a Favorite and types the following
name for it: "Laziness: The Secret to Happiness". An error message will say: "A filename cannot
contain any of the following characters: \/ : * ? " < > |". What filename? On the other hand, if the
Web page title already contains an illegal character, Internet Explorer will just quietly strip it out.
The loss of data may be benign in this case, but not what the user would have expected. Quietly
changing data is completely unacceptable in most applications.
M
ODEL-DRIVEN DESIGN
calls for working with only one model (within any single context, as will be
discussed in Chapter 14). Most of the advice and examples go to the problems of having separate
analysis models and design models, but here we have a problem arising from a different pair of
models: the user model and the design/implementation model.
Of course, an unadorned view of the domain model would definitely not be convenient for the user
in most cases. But trying to create in the UI an illusion of a model other than the domain model
will cause confusion unless the illusion is perfect. If Web Favorites are actually just a collection of
shortcut files, then expose this fact to the user and eliminate the confusing alternative model. Not
only will the feature be less confusing, but the user can then leverage what he knows about the file
system to deal with Web Favorites. He can reorganize them with the File Explorer, for example,
rather than use awkward tools built into the Web browser. Informed users would be more able to
exploit the flexibility of storing Web shortcuts anywhere in the file system. Just by removing the
misleading extra model, the power of the application would increase and become clearer. Why
make the user learn a new model when the programmers felt the old model was good enough?
Alternatively, store the Favorites in a different way, say in a data file, so that they can be subject
to their own rules. Those rules would presumably be the naming rules that apply to Web pages.
That would again provide a single model. This one tells the user that everything he knows about
naming Web sites applies to Favorites.
When a design is based on a model that reflects the basic concerns of the users and domain
experts, the bones of the design can be revealed to the user to a greater extent than with other
design approaches. Revealing the model gives the user more access to the potential of the
software and yields consistent, predictable behavior.
[ Team LiB ]

---

[ Team LiB ]