Naming - The hardest thing in Software
leenaJanuary 31, 2017
There are only two hard things in Computer Science: cache invalidation and naming things.
– Phil Karlton
All of us struggle with naming on a day to day basis. What should we call a class, a field or table in the database or an action in the controller? The fact that it is harder to change it later adds to the complexity too.
Ubiquitous Language
There are techniques that help you arrive at better names. One of them is called Ubiquitous Language - a common, shared language that the developers and the domain experts/users use to communicate.
The best way to arrive at a common language is through conversation. Let's look at an example of how to use conversations to arrive at Ubiquitous Language.
Good Karma is a Phone CRM product we are building for Yoga Studios [yes, it is our own product :)]. The IVR system automates the enquiries the studios receives for different kinds of classes they such as normal yoga classes, ayurvedic classes, yoga teachers training, dietician courses to name a few.
Here’s an interesting conversation I had with a Yoga studio founder -
Leena: Hi Naveen, I had a few questions about different types of yoga classes that we should handle in the system. Can we discuss those now?*
Naveen: Sure. Did you mean Group class, Teacher’s training etc? We call them Business Lines.
Leena: Oh ok. Yes, I meant Business lines. Can you give me examples of how bookings work for each of them?
Naveen: For Group classes, we offer Trial classes so that the customers can get a feel of the sessions and about the teachers too. Some customers are particular about certain Senior teachers, so we need to make sure that the system allows the customers to choose a specific teacher in case they prefer so.
Leena:Do trial classes exist for other business lines too? Say for Teacher’s training or Ayurvedic courses?
Naveen: No, it depends on the business line. For Teachers’ training, usually the customer’s give their details and we get back to them when the course starts. It is not as frequent as Group Classes.
Naveen: Forgot to mention another thing - these depend on the branches too. Certain branches don’t offer trial classes.
_Leena: _One more question. You mentioned senior teachers; do you have any other kind of roles?
Naveen: Yes, there are Studio managers. In some branches, they could be senior teachers. But not all seniors teachers are managers. Apart from that, we have founders, i.e. people like me who started the studio.
The advantage of having such conversations is that it will help you identify more than entities and names - even the actions or rules of the system too.
I’ve highlighted the important terminologies that the customer uses and the same should be the used for conversations among the team members. This will get reflected in the code too. For example, in the above conversation, I started off with the term Yoga classes instead of Business lines. Had it not been corrected by Naveen, the term services would have shown up in the code too.
After having conversations such as these, we convert them into story maps or flowcharts as given below. This helps us to visualise and create a common understanding within the team.
Domain-Driven Design
Ubiquitous Language is one of the key parts of Domain-Driven Design, where the premise is initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
It is much deeper, the following mindmap should give you a quick overview and depth of this.
If done well Domain-driven design helps you move to a Microservice Architecture. I will be covering more about domain driven design in the future posts.
Further References
Ubiquitous Language - By James Shore
Domain Driven Design: Tackling Complexity Software in the Heart of Software
Pluralsight Course - Domain Driven Design Fundamentals
Pluralsight course - Domain Driven Design In Practice