Some recent discussions revolved going back and forth on DESIGN.
For me… design is a multi-faceted thing… Sometimes it is a very high-level part of the overarching theme of what drives an application’s details. Generally, the design is the means by which superior business advantage is gained by our clients.
- For an insurance agent portal application (gather data about the insurance requirements and submit…) we are building now, one of the running jokes is “Everything is a Question.” That is because my overarching design of the system is a domain model surrounding the questionnaire aspect of the system. Add to the questions meta data for the rating system (to auto-generate the XML stream for rating). The entire UI is driven dynamically by the questions set up in a questionnaire — the sample questionnaire that demonstrates all API features and rules is a Diner! Need a piece of information sent to the backend rating system? Create a hidden question and some rules to assign the answer. Need a fancier UI for some questions? Add a CUSTOM_UI meta tag and the UI will kick off a different component for that question(s).
- For a patient clinical summary system we designed, the overarching technical aspect of this design was the “Form” — basically a set of information needed for a patient. Working backward from this request, the proper data was pulled in by autonomous agents, shoved into a “worksheet” for processing. This multi-agent system used descriptive “Semantic Web” technologies such as RDF and OWL for knowledge representation, mapping, and processing.
- For a fire department web-based preplanning system, i used a very brute force technique to implement 50 domain objects in J2EE. Though the 2-tier menu system is table driven, the bulk of the beans are repetitive. Yes, I thought about MDA. Yes, I thought about building it in a completely meta driven manner. But, this was a homegrown, entrepreneurial project, so we used a proven and simple technique that I could deliver more rapidly.
For the first two cases above, the combination of design ideas, sketches, wiki explanations and code will give you the fastest ticket to joining the team and becoming productive.
For the 3rd example, you could jump in on examining source code for any of the 50 objects and know all there is to know about the design and start coding.
design is in the eye of the beholder also… the facets of the design that you choose to share are generally for a specific reason. Maybe for the stakeholder to understand the business value that an advanced design provides… Or, a combination of showing the application architecture + the domain models + code samples for the entire set of layers for the technical architecture is what is best for developers. To discuss the UI design, that is a whole other ballgame.
Another way I like to think about folks (like Ron Jeffries) considering the “Code IS the design:”
- code is reality design is intent