When I first started working as a software engineer I gradually started spending a lot more time designing than actually implementing. More often then not, designing the system to correctly fix the problem of the business is harder than implementation. This is why I started to focus more on design and as I'm currently reading Domain-Driven Design: Tackling Complexity in the Heart of Software I decided to write my notes about it as articles here; to better understand it and maybe help someone get the gist of it without having to read it.

In this article I will write my notes on Part I (chapters 1,2 and 3).

What is Domain-Driven Design?

Domain-Driven Design is a software design approach that focuses on modelling the software to match the business domain.

The book uses the term "model" to express the organized and selectively abstracted knowledge of the domain experts. Meaning that it's not about a specific diagram, document or "model" in the context of programming. But basically whatever shows what the system should do and how to do it is referred to as the model.

The domain is used in the book to refer to the business domain so if your software is for booking taxis, the domain would be the business of ride hailing.

The Utility of a Model

In the preface of part I, the factors defining the utility of a model are:

1. Model and Implementation shape each other
2. Model language is used by all teams (technical and business)
3. The model is the shared understanding of the domain (shared by the developers and the domain experts)

Chapter 1: Crunching Knowledge

The first chapter explains the process of creating a good model. The process should involve meetings between the developers and the domain experts to create the model and refine it to achieve the business goal.

The process is iterative, meaning that it's not a single meeting but multiple meetings that all incrementally create an effective model.

Effective Modeling

These are how modelling should be to produce an effective model

1. Bind the model to the implementation.
2. Cultivate a common language based on the model.
3. Develop a knowledge-rich model that shows the objects' behavior and how that solves the problem.
4. Distill the model by removing unnecessary details.
5. Brainstorming and experimenting.

Chapter 2: Communication and the Use of Language

The model's language is the set of terms and relationships that are used in the model. As explained in chapter 1, the model's language should be understood by both domain experts and developers. Meaning, it should be tailored to the domain and be precise enough to be used for technical development.

As the model keeps changing to better fit its purpose, the language evolves as well by input from both the domain experts and the developers. A good language should be used by all teams and if that's not the case; then the model should be enriched to provide a good common language.

In the meetings, involved parties should play with words and phrases to find the easiest way to express the domain and model it. It's ok to abstract technical details for the domain experts but the core model should be known to them.

Diagrams

It's important to know that diagrams do not need to have the full context of the model. The goal of the diagram is to explain the model and they should be as simple as possible. You should use diagram and documents to explain the model but they don't have to be a replica of the model. In my opinion, a good model should be simple enough that it's understood from the code itself.

Chapter 3: Building Model and Implementation

This chapter stresses on the importance of binding the model to the implementation. A model can be very descriptive of the domain while being unrepresentable in code. If the implementation is not considered while building the model:

• The model can have objects and relations that cannot be stored in a database.
• Model will detail irrelevant subjects and ignore important subjects.
• Some discoveries about the domain might not be apparent without considering the implementation details.

Design Model vs Analysis Model

There are 2 types of models:

• Analysis Model: Captures the fundamentals of the domain concepts in comprehensible, expressive way. (Focuses on the domain)
• Design Model: Specify a set of components that can be constructed using programming tools and correctly solves the problem. (Focuses on the implementation)

The book introduces another approach Model-Driven Design.

Model-Driven Design

Model-Driven Design integrates both Analysis and Design models and it serves both purposes.

To build the model:

1. Design the model to reflect the domain in every literal way.
2. Revisit the Model and modify it with implementation in mind.

If you have multiple systems then they can have different models, however, within a single sub-system you should have only one model. Development of that system then becomes an iterative process of refining the model, the design and the code as a single activity. If the code changes then the model must be changed and vice versa.

Modeling Paradigms and Tool Support

Object-oriented languages (Java) are powerful for implementing the model since they are already based on a modeling paradigm.

Logical languages (Prolog) are also a good fit for model-driven design because they declare a set of logical rules for the design to follow.

Purely procedural languages (C) are not a good fit because it has no modeling paradigm. Procedural languages rely on telling the computer what to do step by step and that's it.

Letting the Bones Show

The underlying model of the system should be the same model shown to users. Otherwise, confusion will arise and the language will not be descriptive enough. Having different models can also cause unexpected behaviors to the users. An example to that is how Microsoft Internet Explorer modeled the bookmarks.

For the user, "Favorites" was a list of URLs but to the actual implementation a "Favorite" is a file that contains a URL. This meant that URL names had to follow windows file naming restrictions. So if a user saved a URL and named it "AOT: 3" they will get an error stating that file names cannot contain special characters like ":" which is very confusing.

Hands-On Modelers

Separating the responsibility of the modeling and coding between different team members violates binding the model to the implementation. It eventually renders the model useless therefore the developers should be able to express the model and contribute to it and anyone who touches the model should participate in the implementation.

Conclusion

Part I is basically a motivation for why Domain-Driven Design is important. It explains the goals of the approach and shows what it hopes to achieve.

My biggest takeaway of Part I is that both domain experts and developers need to be involved in the modeling process and that having a common language that is understood by everyone involved is crucial.

I also couldn't help but notice how well this approach goes with the Lean approach introduced by Eric Ries in his book The Lean Startup. Specifically the focus on experimenting and iterations.

There are modeling examples in the book that better explain the approach's goals by showing the do and don't of modeling so you might want to have a look at that.