A Prepilogue

By Dan Byström

Now you're sitting here, admiring your work: the most perfect Domain Model ever to see the light of day. You have managed to do what at first seemed like an impossible mission: you have mapped a large part of your customer's business to your Domain Model. Not only thatyou have gotten rid of quite a bunch of special cases and shown your customer a more general view of their business than they could ever imagine.

And if this wasn't enough, the interface is clean and the code is even cleaner. Whoever it is who uses this Domain Model will gasp in amazement at your achievement and secretly envy you. What more could you ask for? Now you can surely die happy!

"Did you say whoever? Who is whoever in this case, anyway?"

"Well," you say, "it is any programmer who uses a .NET-enabled language." (Or you may say that it is all Java developers, or some other group, depending upon your implementation.)

"So hundreds of thousands of programmers may use your Domain Model? That's quite something!"

"Yeah, isn't it just great?" you answer. "I have encapsulated a big chunk of the business model as well as the whole issue of data storage into this model so it can easily be used without having to mess with these gory details."

"Are you sure nobody but programmers will be interested in using your Domain Model?"

"What do you mean?"

"Well, I'm just curious... don't you think that there are a lot of users out there who would like to benefit from your work? In fact, isn't it the users who ordered your Domain Model in the first place?"

"Yes that's true. What are you getting at?"

"Don't you think that you need a user interface in order to let these users come in contact with your brand new Domain Model then?"

"Oh..."

I currently have the good fortune to be working with Jimmy on a project where he focuses on the Domain Model and does the O/R Mapping, while I focus on the UI. As a lucky twist of fate, it so happens that we both feel like winners and think that the other one has pulled the shortest straw.

When I develop an application I consider the UI to be the central part, because without the UI the application won't be, well, usable. This is equally true for data representation and data storage part as well, in most business applications. What it really comes down to is just a matter of perspective, personal taste, and interest.

Some programmers don't seem to have a problem with mixing direct DB access right into the UI. One extreme example of this is obviously classic data-binding, in which you bind your user controls directly to database fields. Every time I've tried that I've promised myself never to try it again! (On the other hand, I'm really looking forward to finding an easy way to bind directly to the Domain Model.)

As the application grows and has to be maintained, logical layers come as a blessing.

Having the data of the UI logically bridged away in a separate view, a Presentation Model [Fowler PoEAA2], is yet another great enhancement.

I really can't say I live up to this myself when it comes to simple UIs, but for the tricky parts I definitely do it this way, even if it's not totally pure all the time. I'm sad to say I don't work with projects with unlimited budgets. (On the other hand, if the problem is simple, only a simple solution should be used.)

In fact, the very first time I faced a SQL Database (before that I had always coded my own storage mechanisms, which I still prefer when possible) I immediately realized that I needed some kind of layer between the database and my UI, although it took more than ten years before I encountered the phrase Domain Model.

So a Domain Model is great for UI programmers. But it is really just the beginning. The fun starts here!

Good! Thanks, Dan!

So let's think some more about the presentation services in the context of a rich Domain Model, first from the perspective of a rich client and with a focus on testing.

As Martin Fowler said [Fowler PoEAA], the MVC pattern is one of the most misunderstood patterns around. Still, it's very powerful and widely popular. The purpose and basic idea of the pattern isn't so hard to grasp, but as usual, the devil's in the details. Christoffer Skjoldborg will clarify how MVC can be applied, and he will discuss it in the context of a detailed example.