Interface Domains
It a long time since I've been having the idea that the User Interface is a Domain on it's own, and while reading Evan's DDD book it's only getting stronger.
First, when I stumbled on what he calls the Smart UI Anti-Pattern, I got a little disappointed. Not with him or the book, but with myself. Would I be too wrong on that?
Here I quote his words:
"Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available [Evans p.77]."
But then I started realizing, this only applies when you're dealing with the U.I. as a layer to interact with your Domain, but not as a concept ubiquitously related to it.
Often always the U.I. is the main interaction that the user has with the software. He could interact indirectly with software in other ways, but it's when dealing with the User Interface that he perceives the most business value that he expects when interacting with the software development process. That's one thing that I was always sure about and one of the reasons that I think makes Agile close interactions so invaluable.
But the thing is: User Interfaces are a Domains on themselves.
And I mean Domain, as Evan's presents it.
Whenever a developer works with a Domain model; a clear, concise, business valued model. He deals with core business concepts. Concepts related with business experts experiences and their knowledge with the problem at hands, and transcribing these knowledge to Interactive Interfaces has to major concern points:
- Even if a team captures the Domain in the most precise way, it's generally when translating it to the U.I. that that is the greatest diffusion between the concept and the implementation.
- Grasping business concepts is hard. I had some projects in the past where interviewing business experts separately and together led to two completely different set of responses. But presenting the same people the U.I. (prototyping) led to a fairly greater number of different responses.
These two points make invaluable the abilities, of:
- create/change the User Interface without affecting core domain concepts.
- apply constraints in a way that do not defy business constraints and yet are business constraints on themselves.
- present/relate Domain concepts as Entities, Value objects and aggregates without violating the concepts meaning.
Those are small but important points on establishing cohesion between design and implementation, specially on a Web environment, and that why that DDD concept comes to our help again.
In my point of view, the same concepts that's applicable to Business Domain Modeling are applicable to Interface Domain Modeling.
In a interface you can have:
- Repositories, for retrieving and persisting Interface data.
- Services, for complex operations between Interface elements.
- Factories for creating Interface elements and components.
- Even more advanced concepts as Anti Corruption Layers are applicable as well, when creating Facades for decoupling the use of legacy U.I. components.
Those examples above are specially true when working with R.I.A.
Well, as any developer does (or should ;p ) I've started coding these concepts and with that, a new Stormwind Project is on it's way and I hoping I'm blogging on it soon.
Stay tuned.