What good is a model on paper unless it directly aids the development of the running software
Model Driven Design
Tightly relating the code to an underlying model gives the code meaning and makes the model relevant
The analysis model is not created with design issues in mind, and therefore it is quite impractical for those needs
Some knowledge crunching happens during such an analysis, but most of it is lost when coding begins, when the developers are forced to come-up with new abstractions for the design
The pure analysis model even falls short of its primary goal of understanding the domain, because crucial discoveries always emerge during the design/implementation effort
Pure analysis model gets abandoned soon as coding starts and most of the ground has to be covered again
A deadly divide opens between analysis and design so that insight gained in each of these activities does not feed each other
Model Driven Design discards the dichotomy of analysis model and design to search out a single model that serves both purposes.Each object in the design plays a conceptual role described in the model
Design a portion of the software system to reflect the domain model in a very literal way. Demand a single model that serves both purposes well, in addition to supporting a robust Ubiquitous language
Modelling paradigms and Tool Support
To make MDD pay off the correspondence must be literal, exact within bounds of human error
The real breakthrough of object design comes when the code expresses the concepts of the model
It would take several iterations of refactoring and knowledge crunching to distill the important concepts of the domain into a simple, incisive model
Letting the Bones show: Why Models Matter to Users
Quietly changing data is completely unacceptable in most applications
Revealing the model gives user more access to the potential of software and yields consistent predictable behaviour, when a design is based on model that reflects the basic concerns of a user
Hands-On Modellers
Software development is all design
Over separation of responsibility for analysis, modelling, design and programming interferes in the MDD
When a modeller is separated from the implementation process, he or she quickly looses a feel for the constraints of implementation
Programmers are modellers, so it is better to setup projects such that programmers do good modelling work
Anyone responsible for changing code must be able to express model through code
Success with MDD is sensitive to detailed design decisions
A domain model can be the core of a common language for a software project. The model is a set of concepts built up in the heads of people on the project, with terms and relationships that reflect domain insight.
Ubiquitous language
Across the linguistic divide, the domain experts vaguely describe what they want. Developers, struggling to understand a domain new to them, vaguely understand.
The indirectness of communication conceals the formation of schisms, different team members use terms differently but don't realise it.
A project faces serious when its language is fractured. Domain experts use their jargon while technical teams have their own.
Translation blunts communication and makes knowledge crunching anaemic
The over head cost of all the translation, plus the risk of misunderstanding is just too high.
The vocabulary of Ubiquitous language includes the name of classes and prominent operations.
Same model should supply the language for the developers and domain experts to talk to each other
Persistent use of Ubiquitous language will force the models weaknesses in open
Use the model as the backbone of the language. Use the same language in diagrams, writing and especially speech
Resolve confusion over terms in conversation, in just the way we come to agree on the meaning of ordinary words
Recognise that a change in the Ubiquitous language is a change in the model
Developers should watch for ambiguity or inconsistency that will trip up the design
The language carries knowledge in dynamic form
Modelling out loud
The detachment of speech from other forms of communication is a particularly great loss because we humans have a genius for spoken language
One of the best ways to refine a model is to explore with speech
It is vital that we play around with words and phrases, harnessing our linguistic abilities to the modelling effort
Our brains seem to be somewhat specialised in dealing with complexity in the spoken language
We can exploit out innate talent for grammatical, meaningful language to drive model development
Find easier ways to say what you need to say and then take those new ideas back down to the diagrams and code
One Team, One Language
Domain expert is assumed to be capable to thinking deeply about his field. If sophisticated domain experts don't understand the model, there is something wrong with the model
The developers and domain experts can informally test the model by walking through scenarios, using the model objects step by step
Documents and diagrams
UML diagrams are good at communicating relationships between objects, and they are fair at showing interactions, but they do not convey the conceptual definition of these objects
Attributes and relationships are only half the story of an object mode. Behaviour on those objects and the constraints on them are not so easily illustrated
Diagrams are means of communication and explanation and they felicitate brainstorming. they serve these ends best if they are minimal.
The vital detail about the design is captured in the code
Always remember that the model is not the diagram
Written design documents
Spoken communication supplements the codes rigour and detail with meaning
Two general guidelines for evaluating a document:
Documents should complement code and speech
External documents and diagrams do not affect the behaviour of the program so they fall out of sync
Code as a design documents does have its limits. Its behaviour is unambiguous but that does not mean its obvious
Other documents need to illuminate meaning, to give insight into large scale structures
Documents should work for a living and stay current
In addition to saving labour, hand drawn documents have the advantage of feeling casual and temporary
Greatest value of the design document is to explain the concepts of the model
By keeping documents minimal and focussing them on complementing code and conversation, documents can stay connected to the project
Executable bedrock
Still, even when code can mislead, it is closer to the ground that other documents
To communicate effectively, the code must be based on the same language used to write the requirements-the same language that the developers speak with each other and the domain experts
Explanatory model
One model should underline implementation, design and team communication
It is the creativity of brainstorming and massive experimentation, leveraged through a model based language and disciplined by the feedback loop through implementation, that makes it possible to find a knowledge rich model and distill it. << That was mouthful :D
Knowledge crunching
Effective domain modellers are knowledge crunchers
Many models are tried and rejected or transformed
A team of domain experts collaborate, typically led by developers
lots and lots of talk
Good programmers will naturally start to abstract and develop a model that can do more work
The shallowness of knowledge produces software that does basic job but lacks a deep connection to the domain experts way of thinking
The abstractions are true business principles
Continuous learning
Domains that seem less technically daunting can be deceiving, we don't realize how much we don't know !
Knowledge rich design
Business activities and rules are as central to a domain as are the entities involved
Knowledge crunching yields models that reflect this kind of insight
Deep models
As we come to understand the domain, we usually discard superficial model elements
Subtle abstractions emerge that pierce into the heart of the matter
Models of utility call for sophistication both in the domain and in the modelling technique
Knowledge crunching is an exploration and you cant know where you will end up
