Binding Model and Implementation

An overwhelming wall-size diagram whilst large and complex, still contained/captured some knowledge
It took quite a large amount amount of study to begin understanding and breaking it down, although it was likened to 'randomly browsing the web'
It quickly became apparent that this analyst-readable model could not actually be translated into the application by the developers
At a fundamental layer, the model did not provide a guide to implementation
A new ad hoc design was created, with some matching class names from the original implementation, but it was not based on the existing model or any other model
The book gives the example of another project which ended in the same result, with the application being hacked together without regard for object modelling
The end result being a project which is bloated, hard to understand, but was still functional. You also couldn't gain much insight about the purpose of the system by reading the code
Domain-driven design calls for a model that doesn't just aid early analysis, but is the very foundation of the design

Model-Driven Design

"Tightly relating the code to an underlying model gives the code meaning and makes the model relevant"

Projects without a domain model lose out on the advantages of knowledge crunching and communication we have discussed in previous chapters, and a complex domain can quickly overwhelm projects like this
Alternatively, some complex projects attempt a domain model, but do not maintain the connection between the model and the code, the model implementation continually diverges and only serves as a distraction
An analysis model is a popular methodology, being quite distinct from the design, and is usually developed by multiple people
It gets its name due to it being the product of analysing the business domain to organize its concepts, regardless of the part it will play in a software system, it is only meant as a tool
From this analysis model, a design can be created which more focusses on the implementation details
As developers are forced to create new abstractions for the design, the little knowledge crunching that happens during the analysis is all lost, so there is minimal point maintaining the connection between the model and the design
The analysis model in itself also falls short of its primary goal: to understand the domain. This is due to crucial discoveries arising in later steps

"Whatever the cause, software that lacks a concept at the foundation of its design is, at best, a mechanism that does useful things without explaining its actions."

Model-Driven design discards the analysis model and design, in favour of a single model which serves both purposes, each object in the design plays a conceptual role described in the model
Binding a model and design however must not come at the cost of clumsy designs or a weakened analysis etc

Modelling Paradigms and Tool Support

The real breakthrough of object design comes from when the code expresses the concepts of a model
Java and many other tools allow the creation of objects and relationships directly analogous to conceptual object models

Model-driven design's level of applicability partially depends on the the programming language used

Java for example, allows the creation of models and relationships, analogous to the conceptual models, whereas a language like C does not
Whilst providing a useful result, the program may not be able to capture all of the meaning
This result is often obtained by complex linked functions based on anticipated paths of execution rather than by conceptual connections shown in the domain model
Object-oriented design currently dominates the majority of ambitious projects, and is the approached primary used for the remainder of the book

Example

Continued example from the first chapter of printed circuit boards
Introduce a special software called a PCB layout tool, it optimises the physical arrangement of nets whilst conforming to constraints placed by the human designers
One problem is that each next has its own set of layout rules
For example, nets can be used to form a bus, grouping them together, which allows for a more manageable task, but the layout tool contains no concept of a bus
One way around this was to write a script which applies the same rule to each net in the bus based of the layout tool's data files
Due to a thoughtful naming convention, an alphabetical search can be done on the nets to accurately group them to form a bus for example
This is a poor way to work, attempting to add functionality through external scripts, leading to poor extensibility, and additionally the implementation infers a bus exists, but looking at the tool, it is not explicity mentioned and therefore does not accurately demonstrate the requirements of the tool

A Model-Driven Design

With the objects being implemented in an object-oriented language, the core functionality becomes trivial (see diagram)
Now that we have some helper utilities, starting the application simply requires initializing the repositories with the imported data
Separating the application like thi allows each of our services/repositories to be tested, including our core domain logic
From here, their could either be GUI, or perhaps it could read rules from a file to be implemented on the bus/nets
Whilst the script might be appropriate for one operation, this new model-driven design scales easily
Keep in mind such a design often takes several iterations of refactoring and knowledge crunching to reach this stage

Letting the Bones Show: Why Models Matter to Users

Example of how users are misled by bookmarks in Internet Explorer
Users think of favourites as a list of sites which can persist between sessions
But the implementation treats them as a file containing a URL, whose filename is put in the favourites list
If the name of the favourite contains illegal characters according to Windows file naming system then a problem will occur
Either they get an error message, or IE will simply strip the character, neither of which are expected behaviours
This problem arises between the difference of the user model and the design/implementation model
We obviously can't always expose the user directly to the domain model - it simply wouldn't make sense, but we can expose some facts to the user

"When a design is based on a model that reflects the basic concerns of the users and domain experts, the bones of the design can be revealed to the user to a greater extent than with other design approaches. Revealing the model gives the user more access to the potential of the software and yields consistent, predictable behaviour"

Hands-On Modellers

Manufacturing is a popular metaphor for software development in that highly skilled engineers design, and less skilled assemble
However, software development is ALL design, over-separation of responsibility can interfere with Model-Driven design
In an example, the Evans recalls working on a project where he was essentially forbid from working with programmers, some of the models intent was lost in the handover due to this lack of communication, and there was no feedback from the model implementation (or at least no immediate feedback)
The people who write code must feel responsible for the model and understand how it works, they must also recognise that changing their code can/will change the model
These problems all arise from separating modelling and implementation, which are normally coupled together in Model-Driven design
Technical contributors must 'touch' the code at some point, developers must contribute to the model and anyone responsible for changing code must learn to express a model through the code