How to condense your domain class diagrams

I was once loosely attached to a team who had been given the job of modeling a particular industry. Lets say it was Insurance.

They were given some money and some offices, and told to go away and create an industry model, which could be used as the basis for customer solutions. One model for all aspects of the industry – think of the time and money it would save in creating solutions, and even more in integrating them together.

The first time I saw the model, it was going OK. They had about 200 domain model classes, with things like Premium and Customer, Policy and Claim, but lots of gaps which they just hadn’t had time to fill.

Second time, a few months later, it was up to 600+. This model was now much more comprehensive, at least in the view of those who knew more about the industry than me. Had all the stuff from the first version, and a whole lot more. They looked to be nearly finished.

The final time, several months later, they had only just finished, and the model was visibly smaller. The pile of paper, which was the printout of the model, was a fraction of the height it had been last time. Back to fewer than 200 classes. What happened?

We looked at the detail. We looked for Policy – the heart of any insurance system.

Nowhere.

We looked again, at about where it was the last time we looked. There was something called maybe Entity_Offering_Link. Which if the Entity is a Customer, and the Offering is ‘Insurance’, then maybe is a policy.

So what had they done? They’d started out by modelling the terms they heard the experts used, then, like good modellers do, looked for common abstractions to make things simpler. And went on and on, finding ever more abstract ideas, to ‘simplify’ the model. Until the ‘Insurance-ness’ disappeared altogether. Entity-Offering_Link could equally be an airline ticket, or a order placed at McDonalds. And links between things no longer had real names. All the ‘stuff’ was connected though a generic class, where the purpose of the link was soft-coded as a variable in the link.

Super flexible. Super abstract.

Super hard to understand.

Melting the pan

If you’ve ever made stock for cooking, you know that you start out with all the ingredients, and a whole lot of water. What you want is the concentrated flavor, so you start to boil the mixture.

Gradually the water boils away, and you get to a rich, highly flavored liquid, which has the concentrated essence of the initial ingredients. Then you stop boiling.

Because if you carry on, what happens is the liquid gets thick and gunky, and eventually goes dry, and finally you start to melt the pan.

This isn’t concentrated anything. It’s a fire hazard.

So be aware when you do your solemn duty as a modeler and make abstractions. Don’t get so cute that the essence of the model goes away, It must still have the ‘stuff’ which makes it an insurance or an airline or a restaurant model. It should not need a modeling expert to explain it to a domain expert.

So if you’re managing such a team, beware of letting them model too long. And get the model reviewed frequently, by people who know the area but not the modeling style. Then get it reviewed for style by a modeling expert, before it’s too late, and your stock tastes of melted metal.

(first published on the “Artful Modeler” blog in 2015.)