I have this mental-model of your standard business application that I’ve been carrying around in my head for the last seven-or-so years… that, fundamentally, it’s all about the entity.
(I like the word “entity” because I think it’s an idea that everyone –including non-developers – can easily understand.)
I guess you could say this is the classic “domain model” approach. Your classes/objects represent real-world things such as claims, orders, customers, products, spaceships, etc. These classes expose data (properties, fields, constants) and behavior (methods, operations, functions).
Jimmy Nilsson briefly mentions (and hints at the promise of) Naked Objects in his book, Applying Domain-Driven Design and Patterns. I think this approach has a lot of merit, though not necessarily as implemented in the Naked Objects project…
For a large class of business applications, OOUIs have known advantages over conventional task-oriented user interfaces. This particularly applies to applications where the user is seen, or should be seen, as a ‘problem-solver, rather than merely a process-follower’. - nakedobjects.org
The key in choosing an entity-oriented versus a process-oriented user interface here is the “people are problem solvers” assumption. I like to bring this worldview into the user experience. That is, have a form/page/view that represents the entity you are looking at and a menu/taskpane/toolbar that let you get at the operations, collections, and associations related to the specific entity.
As an aside: I think the entity/task presentation issue is squarely and respectively addressed in the state/sequential workflows of Windows Workflow Foundation, but that’s another post… So, back to Naked Objects.
If you want to setup your interaction architecture to focus on the entity, I’d argue that your presentation shouldn’t treat the entity as the ”view” (e.g. not an object-oriented UI), rather the entity is “subject” to which you will attach meaning and “context”. Forget the automatic framework that generates a screen based on a domain object. You really want to say: “I’m working with this claim (entity), give me the dashboard and let me spring off into narrow, task and answer-specific tools.”
The real beauty of the entity approach is two-fold:
- Your application can maintain conceptual integrity across all architectural layers: Presentation, Domain Model, Services, Persistance/Database.
- You’re moving people up the value chain. They’re no longer automatons simply there to execute workflow that hasn’t been automated yet. They’re trusted agents who use tools to make good decisions: do more with fewer-but-smarter people. I’d rather work in that environment, wouldn’t you?
I’m going to end it here or this post will never see the light of day. I’ll certainly have more to say on the subject in the near future…
Post a Comment