Domain driven design notes - [3] Binding model and implementation

• Binding model and implementation
• 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