Domain Driven Design – Part I : Putting the Domain Model to Work

Interesting excerpts from Part I :

“Domain modeling is not a matter of making as “realistic” a model as possible. Even in a domain of tangible real-world things, our model is an artificial creation. Nor is it just the construction of a software mechanism that gives the necessary results. It is more like moviemaking, loosely representing reality to a particular purpose. Even a documentary film does not show unedited real life. Just as a moviemaker selects aspects of experience and presents them in an idiosyncratic way to tell a story or make a point, a domain modeler chooses a particular model for its utility.”

“On a project without a common language, developers have to translate for domain experts. Domain experts translate between developers and still other domain experts. Developers even translate for each other. Translation muddles model concepts, which leads to destructive refactoring of code. The indirectness of communication conceals the formation of schisms—different team members use terms differently but don’t realize it. This leads to unreliable software that doesn’t fit together.”

“If the people who write the code do not feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software. If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Meanwhile, when a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraints of implementation.“

Introduction

The introduction to this part contains a section called “The Heart of Software” which I found very insightful. It describes how developers tend to prefer honing their technical skills (by using new technologies, implementation methods etc) rather than spending time to learn more about the domain which is the heart of the software.

Chapter 1: Crunching Knowledge (The model is distilled knowledge)

One of the reasons I am enjoying reading this book is because of the concrete examples and stories/experiences in almost every chapter. This chapter starts of with a dialogue between a developer (the author himself) and domain experts who are together building an initial domain model for a PCB design system. Almost all developers would (should) have gone through such a dialogue at some point and will instantly relate to this example. From the example, the author extracts the ingredients required for effective modelling; at the centre of which lies knowledge crunching. Knowledge crunching can be summarised as the process of extracting relevant knowledge about the domain which naturally forms the domain model which should be the core of the development effort. It helps establish a common language for developers and domain experts to discuss/brainstorm about the project (this aspect is further elaborated in the next chapter). It is also a continuous process and plays the main role in the evolution of the project.

Chapter 2: Communication and the Use of Language (The model is the backbone of a language used by all team members)

This chapter extends upon the common language concept that was introduced earlier. The discussion in this chapter revolves around a pattern that is introduced by the author called UBIQUITOUS LANGUAGE. It is the language that should be used by anyone who is working on the project (developers, domain experts, managers etc) while they are discussing the project. The terms/words of the language should always be consistent with the terms/words used in model (they might be class names, roles etc in the model). So when someone uses a particular term, everyone else will understand it in the right context. If the model is changed, the language should also be changed and if the language is changed, the model should also be changed. So the language and the model should just be two different forms of the same concept (body of knowledge). As the author says “With a UBIQUITOUS LANGUAGE, the model is not just a design artifact. It becomes integral to everything the developers and domain experts do together. The LANGUAGE carries knowledge in a dynamic form. Discussion in the LANGUAGE brings to life the meaning behind the diagrams and code“.

Chapter 3: Binding Model and Implementation (The model and the heart of the design shape each other)

This chapter introduces two patterns. The first pattern is MODEL-DRIVEN DESIGN. This pattern states that the domain model should transcend the boundaries that are traditionally imposed between analysis, design and implementation. All the people involved with implementing the project should work off the same domain model. So the code should directly correspond to the domain model i.e. model and the code should be bound together. If any one of them is changed, the other should be changed as well to maintain consistency. So as a result, the UBIQUITOUS LANGUAGE, the code (implementation) and the domain model will just be different forms of the same concepts (relevant knowledge obtained from knowledge crunching).

The second pattern introduced in this chapter is HANDS-ON MODELERS. This pattern deals with the common/traditional practice of having different teams for analysis, design, development. The pattern states that such divisions damage the integrity of MODEL-DRIVEN DESIGN because whenever there is hand off from one team to the other, information is lost and the model becomes weaker. If the developers are not in some way involved with the creation/maintenance of the model, they are very unlikely to develop an implementation that is consistent with the model. In that case it also becomes very difficult for the person(s) in-charge of modelling to get feedback about the restrictions introduced by implementation concerns (so that they can update the model accordingly) . So both teams will go in two different directions and the model will become irrelevant. Therefore developers should always be involved with the creation/maintenance of the domain model and the people in-charge of the domain model should be involved with the development (implementation).

Advertisement