Monday 19 November 2007

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

1 comment:

Anonymous said...
This comment has been removed by a blog administrator.