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.