BT

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

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

This item in japanese

Bookmarks

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
Style

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.

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

Community comments

  • DDD and UML

    by michael lang /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.