I’m about halfway through chapter 2 and the discussion on vocabulary has really spoken to me. Quite a bit of my accomplishments (or lack thereof) at work have been related to things Evans has suggested:

Excessive Frameworks

A nasty habit I’ve seen (out of myself and others) is the belief that a generic framework will obviate domain knowledge. I’ve written plenty of small frameworks, and I’m convinced that the only good framework is a domain-specific framework – anything else is best left as a library.

Modeling Vocabulary

I’ve also run into cases where a domain model has grown without any experts (not because no experts were available, but because the domain wasn’t entirely focused yet). Vocabulary was fickle:

  • Should a user’s computer (identified by a MAC address) be “hardware”, or “device”, or “computer”, or something else?
  • For that matter, should a user be instead “customer” or “client”?
  • And what about the customer’s personal data: “account” or “profile”? A customer has a username and password, which sounds like “account”, but what if the domain grows and a customer can have multiple usernames tied to a single payee?

The end result of a shifting domain and insufficient forethought into the model vocabulary is that some model names have drifted:

  • Between “device” and “hardware”, it made most sense to refer to a term that nontechnical users may be familiar with: “device” was chosen. While in-page text was simple to convert, some web URIs still now refer to the original term, “hardware”.
  • Between “customer” and “client”, it made sense to follow the nomenclature of the underlying billing software: “customer” was chosen. However, the product was initially developed to be as independent as possible from the billing software, so there are scattered references to Client in the source code. The most awkward is seeing a block of code that starts with cust = new Client(...)