Single Responsibility Principle in ServiceNow
Posted on 7 Feb 2021 · 1 min read
I am reading a great book at the moment — Clean Architecture: A Craftsman's Guide to Software Structure and Design by Robert C. Martin — and I keep asking myself: is there anything I can apply from this book to my ServiceNow work? I think the answer is yes.
What is the Single Responsibility Principle?
The Single Responsibility Principle (SRP) is part of the SOLID principles, which describe how to arrange functions and data structures into classes, and how those classes should be interconnected.
The argument for SRP is relatively simple: it makes your system easier to implement and prevents unexpected side-effects of future changes.
A class or module should have one, and only one, reason to change.
What Does "Responsibility" Mean in ServiceNow?
In the context of ServiceNow, your "classes" are your configuration artefacts:
- Script includes
- Flow Designer actions
- UI Policies
- Client Scripts
- Widgets
Example: A client script that validates phone numbers can be said to have a singular responsibility. A client script that both validates and normalises those numbers with their country codes, however, has two responsibilities.
According to SRP, those should be split into two separate client scripts — one that validates, and one that normalises.
Why This Matters
When a single script or flow is responsible for too many things, any change to it carries risk. You might fix one behaviour and accidentally break another. Keeping responsibilities separated means each change is targeted, testable, and safe.
The principle sounds simple, but applying it consistently is what separates a messy instance from one that is genuinely easy to work with over the long term.
For more on Clean Architecture, see Robert C. Martin's book.