After naming the dominant nouns in my domain, I need to describe them:
Which nouns should I model and which not?
What associations do my nouns have?
Whats inside my domain? Whats outside?
(Sorry I tried to write this more simple but I cannot…) A noun is a word to identify a thing [2]. That thing is assosciated with a set of properties (incl. other things). In general we both have a common understanding of a noun used in our language. In other words I can use the word car in a sentence and you and I have a common understanding of what a car is. We would agree that a car has 4 wheels, has a motor and we can drive the car. In other words our associations to car have a high degree of overlap - yet in detail might be different, like my first car was red.
The last sentence implies so much and so little. A leasing agent (leasing domain expert) will agree with the properties of a car above but will assert, that mileage, engine type and damages are missing. Depending on the perspective, we will derive a slightly different understanding of a noun.
Piaggo Ape. Image taken from Wikipedia:
The difficulty as software engineers is to disentangle the ambiguity of nouns. A leasing agent needs to explain to us that a car has 4 wheels (not 3 wheels, those wired Italians ;-) and a power train type (gas, diesel, electric, hybrid). A leasing car can be driven, thus implying that the car is has a mileage and a changing position over time. Also the car is assigned to the JFK airport leasing facility and keeps a record of all damages, repairs and services.
Even more important is, what the domain expert is not explaining. The stuff which is not important to him or the stuff which he pre-assumes! Do I need to model that the car has wipers? Do I need to model the color of the car?
Maybe we software engineers need to be more like Sherlock Holmes interviewing a witness and less like Rube Goldberg trying to model an over-complicated non-sense machine. (Non-sense in the eye of the domain expert.)
A non-sense Rude-Goldberg Machine. Image taken from Wikipedia:
My Spotify Domain
In part 1.1 we identified relationships between Spotify dominant nouns Song, Artist and Listener. Combining nouns and relationships we derive even more nouns and relationships like Album, Playlist and Shared Playlist.
So what is inside our Spotify domain and what is not, is a tough question only our domain expert can answer. But be cautious, the domain is envolving, too! At some point, things change.
Following the idea of Einstein, “Everything should be made as simple as possible, but no simpler.” We should model the essentials of our domain according to our domain expert, yet omit everything else.
There is also another reason. Nouns are names. We should be very reluctant giving names, because naming is hard!
A good name is narrow and consistent [1] and a domain expert should be able to understand what the name represents. (As a side note: I am very cautious when people (incl. domain expert) using complex language. Either they do it on purpose or they try to sound smart yet do not understand what they are talking about. Be more like Sherlock!)
Here is a not so joyful currated list how I would model Spotify.
Song
title
duration
quality
storage identifier
created by (relationship to Artist)
Artist
name
country
genre
Album
title
release date
created by (relationship to Artist)
list of songs (multiple relationships to Song)
Listener
username
password
Playlist
title
currated by (relationship to Listener)
list of songs (multiple relationships to Song)
Further Information
[1] The book Elements of Clojure has a whole chapter on naming. I highly recommend the book. https://elementsofclojure.com/
[2] Oxford Dictionary https://www.lexico.com/en/definition/noun