Domain Driven Design: Another buzzword?

A few weeks ago I bought the book "Domain Driven Design" by Eric Evans. For many years I've been very sceptical about "Design Methodologies", because they seem complicated and not really practical for the domains I've been working on. So, I did not expect too many new insight when I started reading the book....

How wrong I was! Ok, lets start from the beginning... The basic idea of Domain Driven Design is to come up with a language to describe the problem domain. This is called an "ubiquitous language", because the language is not only used in conversations but also in the formal model. The formal model is represented and implemented in the programming language of the system (e.g. java). This is a very agile process, as you understand the domain better you will update the model. The model reflects the understanding of the domain. Your understanding of the domain evolves, by discussing with the domain experts using the ubiquitous language. Keep the model and the design documentation up to date with your understanding of the domain. Because the language we use to talk about the problem domain is the same language we use when we talk about the model, we can reason on the formal model and see if the conclusions make sense in the real domain. This might sound like the simple approach: every "thing" you talk about in the problem domain is an "object". But it goes far beyond that. The idea is to distill the essence of the domain into the core model. Read Chapter 1 of Erics book to get some more insight on what Domain Driven Design is.

For many years I thought that I'm happy to work in a domain, where we, the developers, are the domain experts: I've been working on IDEs for more than 12 years (SNiFF+, eclipse). Before that I've been working as a scientist (physicist) in the area of computational molecular biology. Here again, "we" were the domain experts. No messing with "computer illiterate" domain experts. But after reading Eric's great book, I came to the conclusion, that being your own domain expert might make the design much harder, because it's so easy to get lost in the implementation details and so hard to come up with a ubiquitous language that represents the domains perceived by the user.

When I look at eclipse, I see that many areas of great design at the level of implementation and overall architecture. There's a great plugin infrastructure and the APIs are well though out. However, I also see some shortcomings when it comes to the domain models of the problems eclipse really wants to solve. Simply put: not all eclipse users are eclipse plugin-developers and the domain of software engineering lacks clear models in some places.

I also started looking into what we have done over the years and I realize that we ignored many of the principles of Domain Driven Design. I can see many areas where we should start building better models, making implicit concepts explicit, talking more to our users, not assuming that we know how software development works.

For many years I have been saying, that the documentation team should be part of the design team, because they have to "explain" the concepts at the end. My assumption is: software that is hard to explain is hard to use. Therefore, I thought that the documentation team should come up with the terms and the language to describe the system. They know the language best. In some sense, I was mentally putting the documentation team into the role of the domain experts. I also thought that my "language" problems have to do with the fact that English is not my mother tongue.

Domain Driven Design is like a revelation to me! I realized already that language is important but I never thought of formalizing the language into a design.

Now I'll take a fresh look at our designs. Let's see how this new insight helps me in my daily work....