Domain-Driven Design: Strategic design

Eric Evans visited the January meeting of Oslo XP Meetup for a talk about Domain-Driven Design, and this post is a summary of his talk.

Context mapping

Generic subdomains

A standardized domain which can be bought off the shelf, e.g. an accounting module.

Supporting subdomains

The parts of the system which is required, but which is not important enough do make or break your business.

The core domain

The core domain is typically built by 5-10% of a software system and is the areas and features of your software which are so important that they differentiate your business from your competitors’ businesses. The business should put all efforts into getting this part of the system as good as possible. The core domain will depend on the supporting domains.

Example:

The star rating of books at Amazon helps the customer get the right book. But rating is not strictly required for customers to buy books. The rating functionality is thus a part of Amazons supporting domain.

EBay also has a star rating system. This system doesn’t rate the product, but how trustworthy the seller is. Since trust is essential for a customer to buy something at EBay, their star rating system is a part of the company’s core domain.

“The hackers” and the core domain

Why do often the irresponsible, lesser skilled programmers who care nothing about good software design become the heroes in the organization?

From the customers’ and the leadership’s perspective, the heroes are the people who build the most valuable and useful features, and these features are often the core domain.

On the other hand, the skilled developers often focus on “platform” related architecture and features instead of the core domain. This may be fatal for the company if the “hackers” are allowed to build a badly design core domain which ends up in a Big Ball of Mud.

Good design has business value! Eric suggests putting your most responsible and skilled developers on the core domain and fire the bad ones.

Bounded Context – A system will always have multiple models

The enterprise model is a bad idea. Rather each team should build their own model with a clearly defined bounded context. This will result in clean, well defined models within each context instead of Big Ball of Mud models which try to do everything.

Strategic design and legacy systems

The conical dilemma regarding old legacy software is: Keep the existing system or build a new one from scratch?

Eric describes three different strategies:

1. Rebuild from scratch

This strategy will almost always fail and will certainly take much longer time than estimated. Eric advises against this strategy, unless there are really good reasons (most classical reasons often heard are simply not good enough!).

2. Refactor the existing system

Might work, but most likely the system will never reach the desired level of quality. Lesser skilled developers will continue hacking the system the same way as before, and degenerate the newly shiny refactored parts.

3. Continue hacking on the old system

This is the fate of most systems.

So what to do then? Eric suggests using anticorruption layers to isolates new well-designed domain models from the old legacy system.

Questions from the audience

Two different teams work on an almost identical domain model. Should they use a shared domain model or create on domain model per team?

Eric suggests that each team build their own domain model, even if they overlap and some code will be duplicated. The alternative will lead into creating a Big Ball of Mud.

My own comments to Eric’s talk

I’m currently working on a project where the goal is to replace several old mainframe systems with a new common system on a new platform. According to Eric, this project should have been doomed to fail. In it’s forth year of development and 2,5 years in production the project is still going strong, albeit it has gone through several challenging and difficult periods.

So why hasn’t this project failed then? I think the reason is that the organization I work for previously has made a couple of failing attempt to replace the old legacy systems. This made them learn which costs and efforts are needed to create a new system which replaces the old ones.

The new system will also give a competitive advantage with it’s flexibility in defining new product and price structures, and this added business value is also a motivation for continuing the project.