A ‘new type of customer’ could mean all sorts of things. In my mind it means a new sort of business for the company. It doesn’t seem crazy to me that software w

A ‘new type of customer’ could mean all sorts of things. In my mind it means a new sort of business for the company. It doesn’t seem crazy to me that software work should be required for a new kind of business—there would surely be new contracts needed from the legal department as well as different marketing and possibly accounting or billing. And if nothing new is needed, perhaps they aren’t really a new kind of customer after all. The DDD way to handle customers who must be over 21 is to have some type for the input of your business process, say customeOver21, and some function to which you give a customer and get back either a corresponding customerOver21. This makes sense if the kinds of customer are totally different but if, for example, you are a shop and some products may only be sold to customers over 21, then you probably want some different logic instead (eg each item may correspond to some requirements on the customer (or even some other state, e.g. max 2 of this item per customer) and these requirements can then be unioned together for all the items in a cart.) But however you do things, I think you should work hard to ensure that it is easy to avoid accidentally treating, eg, a customer id as a transaction id or SKU id.