Writing by Peter Hilton

Modelling multitudes

Measuring, counting and naming different kinds of quantities 2022-06-07 #data #design #DDD

Ilnur Kalimullin

Databases typically only support one kind of number, typically with options for how much data to store. A more mathematical perspective includes three kinds of number: cardinal, ordinal, and nominal numbers.

This article focuses on cardinal numbers, which represent quantities. More than one kind of quantity, in fact.

Quantities and precision

Theme park roller coaster rides have a fixed number of seats, which makes it important to count the number of people getting on each ride. You cannot divide this whole number (integer) quantity, because for the purposes of whether a seat is occupied, you don’t model half a person. Measuring each person’s height, on the other hand, uses a different kind of number. When setting a minimum height for a roller coaster, you choose the required measurement precision: to the nearest centimetre, rather than metre or millimetre.

To model a count of people and someone’s height, you use cardinal numbers that represent two kinds of quantities:

  1. multitudes - e.g. 42 children - measure discrete quantities
  2. magnitudes - e.g. at least 1.30 metres tall - measure continuous quantities

Multitudes count the number of items in a collection, while magnitudes measure a size. In modelling, the difference in precision matters.

Naming multitudes

We tend to take it for granted that we name magnitudes, with terms such as height or width, instead of calling them all metres. However, we often get lazy and name magnitudes like people, using the plural of person, rather than naming the specific group. Instead, you might name them riders, insufficiently tall children, and staff.

English has a quirky set of collective nouns for naming multitudes, especially animals. Given a collection of sheep, instead of getting upset about not calling the collection sheep (plural), you can instead call it a flock. However, while these terms of venery have a long tradition and occasional poetry, they don’t often apply to software domain modelling.

If your domain concept doesn’t have a collective noun, making one up doesn’t make you as clever or funny as you think it does. (Although a squabble of children too short to ride the roller coaster seems appropriate.) You might get away with such hubris as a tenured newspaper columnist, but in domain-driven design, you can better discover the collective nouns that people in your domain actually use.

Domain collective nouns

Animals aside, English does have collective nouns for more categories than you might expect, or commonly use. For example, the following terms naturally belong to their domain languages.

Category Collective noun Members
people a cast of actors
people a board of directors
people a choir of singers
things an outfit of clothes
things a bouquet of flowers
things a fleet of vehicles
activities a pipeline of sales opportunities
activities a schedule of conference presentations
activities a festival of concerts
information a calendar of appointments
information a menu of dishes
information a directory of addresses
products a range of computers
products a collection of designer clothes
goods an inventory of warehouse stock items
goods a basket of purchases
transactions a ledger of payments

Exposure to databases, data formats and programming languages tends to narrow your approach to modelling numbers and collections. Your domain models don’t need to share those constraints.

Share on TwitterShare on LinkedIn