This blogpost is part of a larger blog post series. Get the overview of the content here.
Speaking about trade-offs. You’ll face some challenges regarding decomposition. But rest assured composition isn’t a piece of cake either. There are a number of challenges you’ll face and I’m sure there are even more I haven’t discovered yet. But surely you’ll tell me when you stumble over one in your project, don’t you?
For example:
- How do you handle queries?
- How do you handle responses which need to be correlated back to the UI?
- How does a message map to a given User Interface Screen?
- How do you updates status bars?
- How shall the system be deployed?
- How do you do contract sharing?
- How do you manage dependencies?
- How dynamic is dynamic enough?
For querying just don’t use messages. It is going to get you into more trouble then you’ll benefit from it. Queries need a response as immediate as possible. If you use messaging for queries you’ll need complex synchronization logic on the composite UI to bridge from the asynchronous world of messaging back to the UI. Use precomputed read models (see CQRS and Event Source) or just query the data from the database! Databases scale really well as long as you only read from it. Your autonomous “thing” can divide the data as needed (i.e. separate read from write) and use any storage technology which fits the scalability needs.
When responses arrive for a certain message you need to map it back to the UI which triggered the initial request. But wait: Why are you doing request/response style communication? Seriously! Try to talk to the business if this is really necessary. You have all the tools in your tool belt to guarantee delivery, so why on earth does every request need a confirmation? If you nonetheless come up with a business case where you need request/response style communication then please don’t block the UI thread. It is 2014 and we just don’t need to do that! You can use Event Aggregators which are wired up to the controllers or view models. When you send a request you can cache the message id locally. When a correlated message arrives as a response you can use a convention based approach to map from the correlation id to the right screen. And by the way, just don’t use callbacks, they suck! Both from a programming, scalability and maintenance perspective. And if the users insist in having a “synchronous” style behavior on your UI, just trick them as any decent site does (for example Stackoverflow or blog engines).
A screen can trigger multiple messages which is fine. Try to design your User Interface with task orientation. What is the intent of the user? This can usually be mapped pretty well to business scenarios which are fully backed up by your carefully chosen “thing” architecture. Microsoft called the task oriented design Inductive User Interface Design. A well-designed inductive interface helps users answer two fundamental questions they face when looking at a screen:
- What am I supposed to do now?
- Where do I go from here to accomplish my next task?
A screen with a single, clearly stated, explicit purpose is easier to understand than a page without such a purpose. The following steps help to fulfill this premise:
- Focus each screen on a single task
- State the task
- Make the screen’s contents suit the task.
- Offer links to secondary tasks
Talk to your users, get a usability engineer on board, talk with the domain experts, reveal the tasks and mapping messages to UIs will be a breeze!
Have you ever seen a progress bar telling you the truth how long an operation might take? I haven’t! Just don’t use them. In my opinion the best User experience in business applications is when a User can actually carry on with his work while a long running operation is started. Why block the user and force him to stare at progress indicators? That time the user could actually do something productive. If you absolutely need to have progress bars then why not fake the duration? Progress bars lie anyways, just make and educated guess or use indeterminate progress bars. But I’m no UI expert. So talk to yours, I’m sure she/he has better answers!
In the next blog post we’ll cover more challenges.
[…] Challenges Part I […]