The Sweet Spot
On software, engineering leadership, and anything shiny.

Blogging through: Implementing Domain-Driven Design

In recent conversations with coworkers, the topic of Domain-Driven Design has arisen on more than a few occasions in design and architecture meetings. “Have you read it?” a coworker asked, “I think it’d help us a lot.”

I’ve gotten my hands on a copy of Implementing Domain-Driven Design by Vaughn Vernon, which is a more pragmatic approach to DDD than the original Domain-Driven Design book by Eric Evans.

My desire is to share my outlines of the book chapter-by-chapter, hopefully once a week.

Chapter 1: Getting Started with DDD

Can I DDD?

  • DDD helps us design software models where “our design is exactly how the software works” (1).
  • DDD isn’t a technology, it’s a set of principles that involve discussion, listening, and business value so you can centralize knowledge.
  • The main principle here is that we must “understand the business in which our software works” (3). This means we learn from domain experts in our field.
  • What is a domain model? an object model where objects have data/persistence concerns with an accurate business meaning.

Why You Should Do DDD

  • Domain experts and devs on same playing field, cooperation required as one team. (Agile teams, anyone?)
  • The business can learn more about itself through the questions asked about itself.
  • Knowledge is centralized.
  • Zero translations between domain experts and software devs and software.
  • “The design is the code, and code is the design.” (7)
  • It is not without up-front cost

The problem

  • The schism between business domain experts and software developers puts your project (and your business) at a risk.
  • The more time passes, the greater the divide grows.

Solution

  • DDD brings domain experts and software developers together to develop software that reflects the business domain mental model.
  • Oftentimes this requires that they jointly develop a “Ubiquitous Language” - a shared vocabulary and set of concepts that are jointly spoken by everybody.
  • DDD produces software that is better designed & architected -> better testable -> clearer code.
  • Take heed: DDD should only be used to simplify your domain. If the net cost of implementing DDD is only going to add complexity, then you should stay away.

Domain model health

  • As time passes, our domain models can become anemic, and lose their expressive capabilities and clean boundaries. This can lead to spaghetti code and a violation of object responsibilities.
  • Why do anemic domain models hurt us? They claim to be well-formed models but they hide a badly designed system that is still unfocused in what it does. (Andrew: I’ve seen a lot of Service objects that claim to be services but really are long scripts to get things done. There might be a cost of designing the Service interface, but inside things are just as messy as before we got there.)
  • Seems like Vernon is blaming the influence of IDEs for Visual Basic as they influenced Java libraries – too many explicit getters and setters.
  • Vernon throws up some code samples comparing two different code samples – one with an anemic model that looks like a long string of commands and another with descriptive method names. He makes the case that simply reading the code is documentation of the domain itself.

How to do DDD

  • Have a Ubiquitous Language where the team of domain experts share the language together, from domain experts to programmers.
  • Steps to coming up with a language:

    1. Draw out the domain and label it.
    2. Make a glossary of terms and definitions.
    3. Have the team review the language document.
  • Note that a Ubiquitous Language is specific to the context it is implemented in. In other words, there is one Ubiquitous Language per Bounded Context.

Business value of DDD

  1. The organization gains a useful model of its domain
  2. The precise definition of the business is developed
  3. Domain experts contribute to software design.
  4. A better user experience is gained.
  5. Clean boundaries for models keep them pure.
  6. Enterprise architecture is better designed.
  7. Continuous modeling is used – the working software we produce is the model we worked so hard to create.
  8. New tools and patterns are used.

Challenges

  • The time and effort required to think about the busines domain, research concepts, and converse with domain experts.
  • It may be hard to get a domain expert involved due to their availability.
  • There is a lot of thought required to clarify pure models and do domain modeling.

Tactical modeling

  • The Core Domain is the part of your application that has key and important business value – and may require high thought and attention to design.
  • Sometimes DDD may not be the right fit for you – if you have a lot of experienced developers who are very comfortable with domain modeling, you may be better off trusting their opinion.

DDD is not heavy.

  • It fits into any Agile or XP framework. It leans into TDD, eg: you use TDD to develop a new domain model that describes how it interacts with other existing models. You go through the red-green-refactor cycle.
  • DDD promotes lightweight development. As domain experts read the code, they are able to provide in-flight feedback to the development of the system.

Comments