Starts off the chapter by saying unless the model directly aids the software development process, it won't matter how good the model is. With the use of his example, when the developers started implementing the application most of the associations in the diagram didn't translate well into the software implmentation such as storage.
Domain driven design needs a model that doesn't help early analysis but the foundation of the design. Domain driven design requires a different approach to modelling.
Astrolabe used to compute star positions is a mechanical implementation of the an object-oriented model of the sky.
Projects that are complex sometimes attempt to have a domain model but they don't maintain a tight connection between the model and code. Later on the model useful at the start becomes increasingly irrelevant and misleading.
Many design uses analysis model is used as a tool for understanding business concepts rather than how it works in a software system. Not created with design issues in mind and is likely to be impractical for design.
There are knowledge crunching during analysis but the knowledge is lost during the software implementation stages, because developers are forced to come up with new abstractions for the design. Maintaining the mapping/connection between the design and model is not cost-effective.
If the central part of design does not map to the domain model, the model is of little value and correctness of the software is suspicious. Also complex mappings between model and design that is hard to understand will be impossible to maintain when design changes.
There is a divide between analysis and design
Model driven design is using a model that serves both analysis and design purposes.
Code is an expression of the model, if the code changes the model might change as well.
Modeling Paradigms and Tool Support
Talks about languages that are useful for model driven design such as Object Oriented languages rather than procedural languages.
Using the model driven design to implement the PCB example, with net and bus as objects
Each services and repositories can be unit tested.
Model driven design scales easily and can also accomodate testing.
The design does not emerge in a single step, it would take several iterations of refactoring and knowledge crunching to distil the important concepts into a simple, incisive model.
Letting the Bones Show: Why Models Matter to Users
Using examples of saving favourite bookmarks on Internet Explorer, the implementation treats favourites as a file containing a URL, but the user thinks it's a list of URLs.
Quietly changing data is unacceptable in most applications.
Need to create UI that matches the domain model, otherwise it is just a illusion and will often cause confusion.
Using the Internet Explorer rather than having 2 models, just use 1 model and let the user know that Favourites are just a collection of files.
Revealing the model allows the user more access to the potential of the software and yields predictable behaviour.
Hands on Modelers
Seperation of roles in the software development process often leads to problems with the connection of the model and software as there is no collaboration.
People who write the code that don't understand the model or feel responsible then there is no connection between software and model.
If developers don't understand that changing the code, will change the model then their refactoring may weaken the model.
If a modeler is seperated from the implementation process then they won't know the constraints
Problem is seperating tasks that are coupled with each other modelling and impementation.
Better to set up programmers to do modelling work, rather than someone else.
Model driven design connects the model and implementation and with the use of ubiquitous language, the information flow between developers, domain experts and software can be understood by everyone.
Following this method, the result of the software provides rich functionality based on the fundamental understanding on the core domain.