Relationships are more fun

A number of years ago, I was fortunate enough to work for Steve Mellor's company. I remember vividly the first time I met him; I was very nervous. He was reviewing a domain model that I'd built, and I was amazed at how quickly he found a couple of logical flaws. One thing he said during the review has stuck with me ever since: "the fun is always in the relationships". It struck me as strange at the time; as someone schooled in OO, I had come to view Objects as the things that mattered. Relationships? Just pointers between Objects, right?

Wrong. Very wrong. Experience has fully vindicated Steve's assertion that the interesting stuff really does lie in the relationships, not the objects. In fact, the key to understanding any domain always comes down to formalising the relationships among the domain concepts. So I'm constantly frustrated by models in which relationships are second class citizens, demoted to pointers between objects with perhaps a role name. Something like this:
Why? Because it says nothing about the semantics of the relationship. Why does a Customer have a list of Accounts? Moreover, it says little about the domain - and doesn't prompt discussion or questions about the relationship. Can a customer really have more than one Account? How many Customers is each Account related to? What does the relationship mean when viewed from the Account's perspective anyway?

Steve (and my colleague, close friend and boss at the time Alistair Blair) instilled in me the importance of naming relationships using verb phrases. I've found it extremely valuable, more recently adopting the style recommended in Simsion and Witt's excellent book on Data Modelling. So the model above becomes:
With very little extra effort this provides much more information. We now know the relationship represents "Account Ownership". It doesn't cover being an authorised signatory, or a benefactor, or anything else. Are those things necessary? They may be. The point is the model now prompts that question.

The model also makes assertions about the relationship. An Account must be owned by exactly one Customer. Is that right? What about joint Accounts? Again, the model prompts the question. And so on. We can also generate textual facts (or "business rules") directly and algorithmically from the model, according to the technique described by Simsion and Witt. So we'd get:

Each Person may own one or more Accounts

Each Account must be owned by just one Customer

Furthermore, it tells us something about the behaviour, or interaction between Customer and Account. On first glance it's pretty simple: create a new account, assign it to the owner. Job done. But what happens if the Customer goes away? In typical OO programming terms, that responsibility would lie with the customer:

foreach a in self.accounts:
a.delete()

But why should it belong with the Customer? The required behaviour arises because of the Relationship: it's not intrinsic to the Customer. Another case in point is transfer of ownership. Where does that belong? The Customer? The Account? No. It belongs in the relationship.

So the fun does really happen in the Relationships - thanks Steve and Alistair for enlightening me.