Eric Evans: Is Domain-Driven Design Beneficial for Software Development?

| by Jan Stenberg Follow 37 Followers on Jun 16, 2016. Estimated reading time: 2 minutes |

Over the last couple of years, the interest in Domain-Driven Design (DDD) has increased, Eric Evans noted in his keynote at the recent DDD eXchange conference in London. He believes we are in a time when developers care more about design, partially because we are working more with distributed systems in which models have a higher value.

Evans believes that one of the reasons DDD is still interesting is because we challenge the assumptions underlying it and have had some good results from this. One way of challenging it is to ask questions such as:

  • Does DDD help us deliver software faster or better in some definable way?
  • Does DDD help us adapt; can we apply the same principles in an IT world that has changed radically in the last 10 years?
  • Do the DDD principles help us innovate; are we doing software design better now because these principles help us to find new ways of doing things?

The DDD principles depends on us thinking about models in a certain way, but in Evans' experience, people too often reduce a domain model to a UML diagram. Although a data schema is an important aspect, it’s not what he is referring to by a model; the various dynamic aspects are also important. Completeness or a description of reality is not a goal; a model should have a narrow focus and be useful in some specific way. He compares it with a Mercator projection which is a model of the world created specifically for navigation but not especially useful for other purposes.

Often, Evans finds that people get stuck when they trying to create models so elegant, that there is now way to get there in one step. Instead, he believes we should deliver models that aren’t that great and start to use them. We can then learn and create better and better models until we finally have a model that we can be proud of.

Evans emphasizes that we shouldn’t narrow in on what models look like. His view on models include a lot of distinct model paradigms:

  • Object orientation with a focus on things which in turn bring actions. This was the main technique when Evans wrote his book about DDD.
  • Event sourcing, where the sequence of events becomes central and the things are secondary. It has many advantages but also some drawbacks. Evans notes that event-oriented modelling seems to fit a lot of business processes very well.
  • Relational is a set-oriented model suitable for problems in which a lot of things are compared or related to each other. Evans notes that we should use it for what it was meant for, not just a bad way of persisting OO data.

One example in which Evans believes DDD has helped us innovate, is Event Sourcing. It is a different style of modelling a domain with a shift in thinking, from changes in data structures into what’s happening. In certain domains, discrete events relating to things that have happened can be very valuable.

Another example Evans mentions is Event Storming, which has had some impact in recent years. It starts from the context of events happening in a domain and looks at events as fundamental elements in a model. He believes that Event Storming and Event Sourcing, two techniques that both is working with events, may create a positive effect when used together.

Next year’s DDD Exchange is scheduled for late April 2017 and registration is open.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

DDD and UML by michael lang

Many people think many things about UML.

To some its just entity diagrams. There are plenty of constructs within UML that allow you to express event driven systems, such as sequence diagrams, activity diagrams etc.

You can create other notations to describe the same things, but at the end of the day its just another notation.

A notation doesn't make a methodology, and neither does DDD or UML. I don't actually think the notation chosen really has any impact on how effectively people work together and communicate design concepts. Its more about individuals and their ability to perceive and communicate systems design. What form that communication takes is irrelevant as long as it is efficient and understood by all parties

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you