More than XP. More than one day.

Abstract
A good domain model defines terms and concepts that make sense to both the business and developer, allowing them to communicate. Eric Evans claims that "with a conscious effort by the team, the domain model can provide the backbone for [a ubiquitous] language". Meanwhile the open source Naked Objects framework automatically renders the domain model objects directly in a generic UI (rich client, web and others). In this session we’ll explore how Naked Objects’ ability to animate the domain model allows the ubiquitous language to be developed rapidly, and without any particularly conscious effort on behalf of the team members.

Overview
It's generally agreed that having a domain model is a good thing, and as Eric Evans' DDD emphasises a common domain model should define the terms and concepts that make sense to both the business and developer and by which they communicate. He calls this a ubiquitous language and states that "with a conscious effort by the team, the domain model can provide the backbone for that common language".

Naked Objects is an open source framework which automatically renders the domain models objects directly in the generic UI (rich client, web and others). The only requirement for the developer is to develop the domain classes, while the business sees a direct representation of that in the UI.
We used (and refined) Naked Objects at the Irish Government to develop the online benefits administration system for pensions and other benefits, now in use by ~500 end-users. Our experience was that Naked Objects allowed a ubiquitous language to be developed but without any overtly conscious effort by the team. It is the ability of the framework to "animate" the domain model that allows the business users to readily connect with it and correct it. Because there is this 1:1 correspondence between what the business user sees and what the developer has programmed, they are naturally talking the same language. So, we think this would be an interesting idea to explore at XP Day.

Of course, as any seasoned IT practitioner will know, coupling one's domain model to some framework is a risky affair. Moreover, there will always be limitations as to what any framework - no matter how extensible - can do. Naked Objects acknowledges this in that it the domain models that one develops with it are basically POJOs, with support for a number of additional well-defined semantics within its extensible programming model. In other words, there is almost no coupling to the framework itself, and the domain model can be used as the centre of a conventional JEE deployment if required. This therefore makes it a useful tool for requirements analysis irrespective of whether it is used as the deployment platform. The session will also touch on this point (though given the session's timeframe deeper coverage for those interested will be demoted to a BoF).

Objectives
The objectives of this session are twofold. The primary object is to show how Naked Objects can be used to build a ubiquitous language. The secondary objective is to explore the extent to which Naked Objects can capture all domain model semantics and thus influence whether to deploy the resultant domain model (under Naked Objects, or under some other JEE environment).

Approach
Although I would ideally have liked to have the attendees using Naked Objects for themselves, I want to keep the session into 90 minutes and doing the install and having everyone role-play being customer vs developer would take too long. Therefore I shall take the role of developer and the attendees will take the role of customer/domain expert.

Together we will work on a simple application. This will be easy enough to understand, but will (deliberately) have some issues in terms of the language that has been selected for its domain model. We'll perform a couple of iterations of development, with me (as session leader) doing the development. I'll be guiding the way in which we develop the application (ie which user stories we implement) so that we most fully meet the two objectives of the session.

Timetable

• 0-5: sit-down time.
• 5-15: overview of the core ideas of DDD, namely: ubiquitous languages and model-driven development.
• 15-25: introduction to the sample application.
• 25-30: divide into groups of ~4 per group, with one PC capable of running Flash demos per group. Provide a sample of the application as a Wink demo to each group
• 30-40: exercise #1: working in groups and running through the application, identify any issues or problems with the domain language that has been selected. Capture such points using cards.
• 40-50: (session leader) group cards from all teams together, eliminating any duplicates; collectively decide which points to implement
• 50-60: (session leader) implement (at least one of) the changes.
• 60-70: exercise #2: each group identifies additional domain constraints / semantics / business rule / additional enhancement to the existing application, using the existing ubiquitous language. Write on cards.
• 70-80: (session leader) review the suggested enhancements, and illustrate (without actually necessary implementing the change) how some of the enhance would be extend the implemented without creating coupling to the framework. Will aim to pick one enhancement for each major feature supported by the framework.
• 80-90: discussion/review of session. Is Naked Objects suitable to capture the domain model for your project's application? What sort of domain semantics could not be captured under Naked Objects, and how important were they?

Session Outputs
Conclusions from the final discussion/review, ie how effective was Naked Objects at developing the ubiquitous language and capturing the subtleties of the domain semantics.

Other
For those interested in exploring Naked Objects further the software used by the session leader, plus the Wink demo, will be available to those attending as a ZIPped Eclipse distribution.