When I started building the current iteration of the Street Art Cities platform a few years ago, I decided on the following core entities:
A Site can have multiple Markers, and a Marker is connected to a single Site.
Both of these are somewhat abstract entities. A Marker has a type attribute, which can be either artwork or place. Places are things that aren’t artworks, but still relevant to display on the map, and has a bunch of sub-types: Hall of Fame, Can Shop, Skate Park, Street Art Bookshop, etc.
Sites work the same way, but at launch there was only one type: city. Each Site represents a city that someone can have permission to add markers to, and holds a lot of metadata to render streetartcities.com/cities/{siteId}.
In my mind, there might be other types of Sites in the future - maybe a street art festival would have their own Site, or a gallery. Maybe there would be some other type of Site that I hadn’t thought about yet.
This turned out to be a useless abstraction, since all of those other structures ended up being built as separate entities, as you always want a Marker connected to a specific city, even when it’s also part of a festival or gallery.
Trying to be clever here was a major distraction, and over time, as multiple people worked on the codebase, we started using the works site and city interchangeably in variable names and comments, which is a bit messy.
It would have been so much better to stick to the use cases we fully understood, and have gone with a City entity. If we would have had to refactor later, that would have been easier than ending up with a situation where we’re using not using ubiquitous language for this entity in our model.