Let’s say you’re chatting with business, trying to figure out their domain model. Great. They explain…
- Users answer phones, accepting calls from customers with computer problems.
- The user gathers contact info from the caller.
- The user creates a new ticket.
That’s the intake scenario. Now for the update scenario.
- A call might come in from the customer, or from somebody else.
- The user might also gain information from another source, like a fax, word of mouth, their own knowledge, etc.
- In either case, the ticket is brought up for editing, changed, and then saved.
It can be tempting to have a single domain entity for the above story, let’s name it Ticket. It has fields for Contact Name so who know who has the problem, and Call Date so we can track how long it takes to resolve the issue. Certainly we’d also need fields for status, comments, etc., but those aren’t specific to the topic here. The damage is already done. We have committed one of the great domain crimes… we have conflated multiple domain entities into one!
I’d argue, and in my real life case, it’s clearly true, that the contact information fields do not belong anywhere on the Ticket domain item. They’re two different things. There is a Contact entity, and there is a Ticket entity. Now sure, is a Contact almost always related to a Ticket? Yes of course it almost always is, so they are related, but they are not together! You can have somebody call in, forming a Contact, whose problem is resolved immediately and no ticket is ever opened. You can also have a Ticket where the customer calls in ten times, with updated information and details each time, and you need that captured. And finally, you might be updating a Ticket when there is no Contact for that update at all, the information came from some other source than a phone call. In other words, there is more going on in the domain that you get from an initial naive simplistic model.
In real life I didn’t catch this at first. It was actually a year before I really realized just how badly the domain needed this extra Contact entity. I was a little naive in thinking “surely I can’t understand the domain model so soon” and so I didn’t really try. It would have been helpful to have a trick, a rubrik, for knowing when this was going on.
For example, a client might say “we need a field that holds either the number of days spent, or the dollar amount spent”. I stop right there and try to steer them towards two fields, one for the number of days, one for the dollar amount. If only one or the other makes sense, fine, we can add a validation rule to enforce one of them being blank. But my point is that I immediately detect this as a problem. You can’t have two data types in a single field. It just doesn’t work that way. It’s why we make fun of Prince and his silly symbol so much. Names are always text, not symbols, and if you try to break the rule, everybody laughs at you.
I need a rule like that, that points out missing domain entities, that have been erroneously merged into other domain entities.