Agile Zone is brought to you in partnership with:

I've been developing software with passion for over ten years and for many companies, deeply immersed in the challenging domain of finance. I'm always experimenting on how to improve our craft, in particular with Domain-Driven Design, patterns and agile principles. cyrille is a DZone MVB and is not an employee of DZone and has posted 13 posts at DZone. You can read more from them at their website. View Full User Profile

Key insights that you probably missed on DDD

  • submit to reddit

As suggested by its name, Domain-Driven Design is not only about Event Sourcing and CQRS. It all starts with the domain and a lot of key insights that are too easy to overlook at first. Even if you’ve read the « blue book » already, I suggest you read it again as the book is at the same time wide and deep.

You've Got Talent


The new "spoken" language makes heavy use of the thumb

A new natural language that makes heavy use of your thumbs

Behind the basics of Domain-Driven Design, one important idea is to harness the huge talent we all have: the ability to speak, and this talent of natural language can help us reason about the considered domain.

Just like multi-touch and tangible interfaces aim at reusing our natural strength in using our fingers, Eric Evans suggests that we use our language ability as an actual tool to try out loud modelling concepts, and to test if they pass the simple test of being useful in sentences about the domain.

This is a simple idea, yet powerful. No need for any extra framework or tool, one of the most powerful tool we can imagine is already there, wired in our brain. The trick is to find a middle way between natural language in all its fuzziness, and an expressive model that we can discuss without ambiguity, and this is exactly what the Ubiquitous Language addresses.

One model to rule them all

Another key insight in Domain-Driven Design is to identify -equate- the implementation model with the analysis model, so that there is only one model across every aspect of the software process, from requirements and analysis to code.

This does not mean you must have only one domain model in your application, in fact you will probably get more than one model across the various areas* of the application. But this means that in each area there must be only one model shared by developers and domain experts. This clearly opposes to some early methodologies that advocated a distinct analysis modelling then a separate, more detailed implementation modelling. This also leads naturally to the Ubiquitous Language, a common language between domain experts and the technical team.

The key driver is that the knowledge gained through analysis can be directly used in the implementation, with no gap, mismatch or translation. This assumes of course that the underlying programming language is modelling-oriented, which object oriented languages obviously are.

What Form For The Model?


Text is supplemented by pictures

Text is supplemented by pictures

Shall the model be expressed in UML? Eric Evans is again quite pragmatic: nothing beats natural language to express the two essential aspects of a model: the meaning of its concepts, and their behaviour. Text, in English or any other spoken language, is therefore the best choice to express a model, while diagrams, standard or not, even pictures, can supplement to express a particular structure or perspective.

If you try to express the entirety of the model using UML, then you’re just using UML as a programming language. Using only a programming language such as Java to represent a model exhibits by the way the same shortcoming: it is hard to get the big picture and to grasp the large scale structure. Simple text documents along with some diagrams and pictures, if really used and therefore kept up-to-date, help explain what’s important about the model, otherwise expressed in code.

A final remark

The beauty in Domain-Driven Design is that it is not just a set of independent good ideas on why and how to build domain models; it is itself a complete system of inter-related ideas, each useful on their own but that also supplement each other. For example, the idea of using natural language as a modelling tool and the idea of sharing one same model for analysis and implementation both lead to the Ubiquitous Language.

* Areas would typically be different Bounded Contexts

Published at DZone with permission of cyrille martraire, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Reid Atherton replied on Tue, 2010/11/02 - 12:59pm

Something else that some people miss, but Evans has tended to emphasize in his lectures, is that DDD is most appropriate where it can do the most good: the core domain of the business, around which everything else revolves. The additional layers and process that go along with DDD is simply less justifiable in many cases. For instance, if the domain model is only used by one application and it's only accessed by one interface, then a full-blown domain model may not be worth for it for you.

cyrille martraire replied on Wed, 2010/11/03 - 2:50pm

Hi Reid,

Yes Eric Evans did repeat this message in many of his talks, that not every part of the code deserves the same level of care. In this process he calls Distillation, the core domain, which yields most business value, should be favoured over other sub-domains, that are just necessary. I believe that this idea of focusing efforts on the most valuable parts is also one of the key insights brought by the BDD movement.

However the example you provide does not illustrate that approach, as you don't tell if the domain of this "single application with only one interface" is a core domain for the business, or if it is just a supporting sub-domain, required, but with no competitive advantage. Cheers

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.