12:21 am - sparkle_killer - some thoughts i posted this brain dump in my journal.. just thought i'd share.. see if anyone has faced similar things. to anyone that reads this, this is not a social entry so dont bother.. its just a brain dump of some ideas i have that i need to recall before i develop alzheimers(sp).
Extending FDD for repeatable UI contruction
There are two key issues that need to be addressed in a hierachical architecture. While most systems will be split interally along speration of concerns (user interface, problem domain, system integration and data management), the understanding that human interaction is completely opposing in thought to objective business activity/feature set modelling. That is, when designing for the PD, modelling must be object centric. Since there is a direct dependency defined via an interface in the PD, the SI and DM will always have a dependency to it (acknowlwdged that there will occasionally be transactional dependency from the SI to the DM). I.E. PD <-- SI / \ |
DM While this thought is not new, there has been no real technique to defining then, how any user interface will behave with a problem domain. To objectify human interaction doesnt make sense. Even though as humans, we naturally express in terms of objects, there is unique perpetive that links all these objects together. This is not an operation acted upon by an object, it is an expression defined with multiple objects. This is the heart of the problem space though. Human interaction is user centric. This even comes down to general relativity in some respects! No matter how well the business domain has been isolated, persisted, whatever, the actual system is measured by its user experience. This leads to two questions. How does one define the architectual seperation between the UI and the PD? How does one effectively model the UI considering the best practise for the PD is object centric? My inital thoughts are that to the first question, the problem domain defines a thin layer above it, and exposes a facade(interface) letting a UI client know what sequences can be acted on it (to me the implementation of this interface would call the object responsible for its initiating behaviour in the problem domain). This creates a high degree of coupling to the user interface, which isnt so bad, but not ideal. I havent really thought hard enough about how to expose the PD to the UI elegantly. The second question seems easy enough.. or does it? OK. so object modelling for the PD.. cool. DM and SI arnt terribly difficult after that (still object modelling). User experience.. user centric. Use cases? Statecharts? How the hell do accomplish this effectively? Considering it is pretty hard to replicate MVC with java in a distributed web environment, how does this modelling effectively map to essentially what is object centric?
sparkle_killer - some thoughts i posted this brain dump in my journal.. just thought i'd share.. see if anyone has faced similar things. to anyone that reads this, this is not a social entry so dont bother.. its just a brain dump of some ideas i have that i need to recall before i develop alzheimers(sp).