Recently I’ve started talking more about modeling and its relation to the real world.
Here’s where it all starts from:
Don’t try to model the real world, it doesn’t exist.
I know that that sounds like a very Matrix-y kind of statement, so let me explain.
The “Real” World
The problem with the “real” world is that you are limited by the laws of physics. The thing is that somewhere along the history of software development, we got this idea that if only the structure of our software represented physical reality, then our software would be maintainable, flexible, robust, … in short, good.
The thing is that a single physical entity can have multiple meanings to various stakeholders.
Let’s look at something simple, like a glass:
From a developer’s perspective we might call that a Product and not think very much more of it. We’d be happy that we could come up with a single abstraction that allowed us to model all the different kinds of products the same way.
Yet, in talking with our business stakeholders, one might call it inventory, another might call it a liability (think of breakage requiring insurance), and another call it merchandise. The important thing to note is that the data relevant to each of those meanings is so different from one stakeholder to another.
And that brings me to “customer”
One of my least favorite entities – a lingering symptom of the Northwind disease.
When someone walks into your store for the first time (whether that store is physical or virtual), are they a customer? Even if they haven’t ever bought anything? Even if you don’t know their name? Are they even a User then? I mean, it’s not like we’re going to force people to login (or create an account) just to browse the site, right? A term like Visitor, Prospect, or Lead sounds like it would describe this type of concept better.
After wandering around your store for a while, they come up to you and ask for help finding something. If this pattern repeated itself over and over again for the same category of item, would that be meaningful to the business? Don’t you think that should be modeled? I hope your answers are yes, and yes. This is the domain of merchandising, and seems more related to Visitors than to Customers.
Let’s say your selling to other businesses rather than to consumers. In the B2B space, it is common not to receive payment for goods or services for some time – you might have heard terms like Net30, which means you will be paid up to 30 days later (in some cases, this may be from the end of the month of the invoice rather than the date of the invoice).
If you talk to the business folks in charge of these scenarios, you’ll hear them talk about Accounts Payable and Accounts Receivable. Yep, they are the accountants. If you were to go about building a DDD Ubiquitous Language, it sounds like the term Account would be a better choice than Customer. The thing is that accountants use the same language regardless of how quickly an account is settled – like if payment is done by credit card at the time of purchase.
There is no Customer.
There is no Product.
The same goes for so many other problem domains.
I know it feels counter-intuitive to not have a single class representing a single physical thing. It feels like it’s the exact opposite of Domain-Driven Design. It feels anti-object-oriented. But remember, most stakeholders you talk to don’t focus on the physical elements either.
The one thing left to be modeled from “reality”
And that’s identity.
It would be most accurate to say that the physical thing you perceive is nothing more than identity serving to correlate all the separate business concerns to each other. It’s this ID that ties the Visitor on the site, to the Account, to the Addressee (for shipment).
These IDs are needed primarily for reporting and UI reasons – it isn’t likely to have a business action operate on entities correlated this way in the same transaction.
Nouns, Verbs, and Reality
In building your ubiquitous language, look past the nouns and verbs visible on the surface.
Watch out for statements like “in reality…” and “in the real world…” as they are really just one person’s interpretation of their perception of reality. Not one of us is able to see reality clearly – it’s all just perceptions. Recognize that, like models, all perceptions are wrong, but some may be useful.
Model the perceptions – at least you can have first hand experience of those.
Forget about reality – all that exists is perceptions.
In closing
Transcend the physical.
In software there is no gravity, no mass, and as many dimensions as you choose to create.
Break free of the Matrix.
You are the god of your software.