Speed, Agility, Resilience
Trusted Experts in Microservices, Cloud Native & Chaos Engineering
  • Home
  • EBooks
  • Contact Us
  • Consultancy
    • One-to-One Online Consultancy
    • Onsite Consultancy
  • Training
    • One-to-One Online Training
    • Building Reliable Systems
    • Building Antifragile Systems with Microservices Course
    • Fast Track to Cloud Native Java
    • Fast Track to Applying DDD for Effective Microservices
    • Fast Track to Running Production Microservices
    • Fast Track to Chaos Engineering
    • Autumn of Cloud Native
  • Speaking
    • Schedule
    • Slides and Videos
    • Brown Bag Events
  • Blog
  • FAQ
  • Client Feedback
  • Gallery
  • (Print) Books
  • Essais

Friends don't allow Friends to create Microservices with Codenames

5/3/2016

0 Comments

 
Naming is critical to the human comprehension of your system, and this obviously extends to service naming. Human comprehension is king and so in order to fight the biggest limiting factor on your software system accepting and thriving on change, i.e. you and your comprehension of it, naming is a critical concern.

When naming microservices I recommend you focus on naming a service in terms of what it does, not what it is. PayrollSummaryAggregator, or “PayrollTableView” are named in this preferred way.

Things to avoid include (in no particular order as such):

  • Avoiding nouns
  • Avoiding ‘and’ in the name
  • Avoiding codenames!!!
  • Avoiding Acronyms
So calling services “PeopleService” or “Payroll Service", noun-centric, is a dangerous way of hiding all the things that are happening under the hood. Nouns tend to hide complexity.

If you find yourself developing a service and wanting to use “and’ in the title then it’s a good indication that the service is going to much. This is a good and natural thing; we often build services that start out seeming to do one thing and then realise that it does too much, which leads to reduction and new service extraction.


What about Type?

Calling a service a “Service does not make it a single-concern service that aids comprehension.*

Should you add “Service” to a service’s name? The rule here is only if you have other *types’ of artefact in your system.

If you have stable and reusable libraries then having some things called “Library” and others called “Service” probably aids understanding.

But use a type with care, it can easily lead to too high-level and name and hide multiple concerns and complexity in the service.


A Word on Codenames

Code naming services is fun and often used when we’re not sure what a service will do … yet. However these should be dropped at the earliest opportunity as they:
  • Provide a way of hiding a service that does too much
As a heuristic, if I have to search wikipedia to understand what your service does then the naming is very, very wrong.


Avoiding Acronyms, IYC (If You Can)

The danger of naming micro services with what they do is that it can lead to long service names. That in itself is not a problem, but it can lead us lazy humans to strip them down to acronyms in conversation (both digital and verbal), which then leads to reducing the comprehension of others.

Try to avoid acronymising service names, even if they are long unless you are in a context where the acronym has been clarified.
0 Comments



Leave a Reply.

    Musings on software development

    Archives

    September 2017
    June 2017
    November 2016
    September 2016
    May 2016
    February 2016
    September 2015
    August 2015
    June 2015
    March 2015
    January 2015
    December 2014
    November 2014
    October 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    December 2013
    August 2013

    Categories

    All
    Announcements
    Antifragile
    Books
    Innovation
    Life Preserver
    Microservices
    Philosophy
    Psychology
    Reviews
    Software

    RSS Feed

Products

EBooks
​(Print) Books
Consultancy
Training
​
Speaking

Company

Essais
FAQ
Client feedback
Gallery

Support

Contact
Picture
© COPYRIGHT 2018. ALL RIGHTS RESERVED.


Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.