When a domain model is not enough

Ever since reading Evans' Domain Driven Design, I have been enamored with the idea of the Domain Model as the keystone of application development. 'Build your domain model first', 'The domain model should receive the most attention', 'Minimize your plumbing (non-domain) code' - These have been my mantra for development the past couple of years.

Recently I have been working on a web framework to present a rich object model via HTML without little or no plumbing code. Constraints and hints would be provided to the framework by applying attributes to the domain classes, providing declarative customization. The generic UI idea has various examples like Naked Objects.

What I am coming to realize through this project is that the Domain Model is not really what you want to present to the user, no matter how clever you are in using conventions to render the model elements in a friendly way. There is inescapably a different shape to the model representing what the user interacts with than the domain model.

To be clear, when I refer to a model I am using the term similarly to Evans. A model, most generally, is a tool for us to think about a problem. Here I refer to design models which are expressed in the software itself.

There are meaningful models present in the design of an application beyond just the domain. If we are talking user applications, there is a Presentation or View Model representing how information is displayed to the user, a Navigation model, and more generally an Interaction or UI Model. Working with these explicitly gives you the advantage of being able to use your big brain to create UI abstractions to make your life easier (as opposed to vilifying your UI). To get cute with terminology, the UI for your application is itself a domain that could benefit from a model.

Hasn't this all been settled with the various UI patterns and the frameworks built around them? Not quite: what is the UI model specific to your application? Could this model help you make your UI code clearer and more effective? Next time I will provide an example from our own application.

Fix for annoying auto-update of web.config in web projects

Is Visual Studio adding unwanted references to your web project's web.config file whenever you compile? Found a work-around here that involves appending to the registry entry [HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\VisualStudio\ 8.0 \Projects \ {E24C65DC-7377-472B-9ABA-BC803B73C61A}\ FilteredGACReferences].

Simple Expression + Metadata = Code Generation

This is the idea behind the development tools I'm currently working on. The goal is to express a system implementation in the simplest possible terms using a procedural language (C#). To get an idea of what I mean by "simplest possible terms", see the code in the bowling example from RuleLink. Reading the signatures and metadata from the business logic classes, code would be generated to create a functioning application. Easier said than done.

Now that RuleLink is in a workable state, my next target is a framework for generating application code from the business logic classes. Say that you have implemented a method

NewAccount(string email, string password, bool joinMailingList)

Exposing this method to the framework, you should get a basic generated user form for entering these values. When the form is submitted, the method is invoked. The form could be generated for ASP.NET, MonoRail, or anything for that matter -- as long as the developer can step into the generated code and understand what is actually going on.

This basic form would be sufficient for prototyping an application, but in order to get on to a bona fide solution, we need validation, page flow, layout, styling, etc. These would be implemented using techniques that do not corrupt the clarity of the business logic and do not require coding additional layers that need to be tested and maintained. Validation, for example, might be expressed as:

NewAccount([Constrain(AccountRegistry.AddressExists)] string email, string password, bool joinMailingList)

To change or extend the basic application generation, you would use metadata, configuration, or use-specific components to plug into the generation framework. When actual business logic needs to be applied, you refer back to the business classes (as when we used AccountRegistry.AddressExists above).

Gazintas.RuleLink published

The newly-created Gazintas project promises '.NET tools to enable lightweight and expressive code' and the first component, RuleLink, provides a 'runtime code generator for wiring together side-effect-free functions'.

Light bulbs are for illumination

The best time, sometimes the only time, to capture your ideas is at conception. And the best way to make sure you've captured a cohesive and sensible idea is to describe it to someone else. Enter the blog: you can capture your ideas and receive helpful comments from people probably more intelligent than you. You gain the opportunity to find fame, fortune and, most importantly—connections. Isn't that worth fifteen minutes of your time?