XPDay 2007: Building a Ubiquitous Language Using Naked Objects - Dan Haywood

Irish Govt’s Dept of Social & Family Affairs are very committed to agile

Synopsis

• Eric Evans’s Domain Driven Design — tackling the complexity of the domain itself … not even specific features
• Martin Fowler — models are just a map of the real world, they “are not right or wrong, just more or less useful”
• “Ubiquitous language” aims to unify the vocabulary between business and developers

Tangibles

• Uses reflection APIs to expose domain objects directly in user interfaces
  • (Written in Java 1.1 so can be exposed as a .net dll)
• Goes beyond CRUD as can expose public methods as actions on objects
• DSFA had a green screen environment previously, so any user interface was an advantage…
• Generic user interface:
  • repositories down the left (can locate entities by type)
  • then window shows representation of entity with properties and references to other entities
  • also shows actions on properties (e.g. name —> “Legal change of name”)
  • generic interface needs training to use, but can be skinned
  • protocol between client and server is pluggable
    • Irish system is stateless, has optimistic locking and doesn’t get updates live
• used to build self-contained apps to demonstrate
  • but customers didn’t have enough experience/installed software to properly understand the application
  • so built Wink demos to use in browser’s flash plugin

Development Environment

• Based in Eclipse with plugins
• Uses Spring to tie things together
• Use fixtures for test data — use composite pattern so can reuse over user stories
• Can build as Swing app, web app based on Jetty or RCP app

Business rules available:

• Can hide or disable properties
• Can validate before accepting
• Uses modify before set — in order to set up bi-directional relations

Sister projects:

• Naked RCP
• Naked REST — exposes Naked Objects as RESTful web interface
  • Dan’s project for 2008…

Conclusions

As default user interface becomes good enough, discussion turns to domain model instead.

Wizards are for transient apps (Inmates are running the asylum — Cooper)

• Sovereign apps gets used everyday, all the time
• Naked objects are good for sovereign app and building the domain model (not so good for wizards)
• Could then add a custom object that maintains its own state for building a wizard, or else use POJOs that were generated from within some other framework
• Use Naked Objects for building and debugging the domain model

Q&A

Are there any compromises in order to use Naked Object UI?

• Navigating large collections can be awkward
• Probably want to alter the domain slightly — view most recent, search by date — rather than view all

Since can code quickly, can actually think of pair programming with your customer

What advantages does Naked Objects give over Rails?

• originally, MVC controller was to control the objects; been distorted so that it now controls the user
• Naked Objects allows you to adjust domain easily independent of user controller
• Rails insists on a user controller or just offers CRUD