SNow - Clean Architecture
Clean Architecture with ServiceNow
Introduction
The following set of rules is aimed to provide a maintainable, extendable and understandable architecture for any solution within service now. They are kept as short as possible to allow for a one page document. Please share your thoughts and feedback, as well as your critique.
1 Script Includes are for Data Manipulation
Don’t save. Don’t update. Don’t insert. Don’t delete.
In fact: Script Includes don’t. They provide.
2 Business Rules are for Data Transformation
Do save. Do update. Do insert. Do delete.
In fact: Business Rules do, but won’t think. Therefore, make Script Includes the brain of Business Rules.
3 Client scripts are for displaying data
What do they display? Data! Where do they get it from? Queries! Do they think? No! Do they do? No! But what are they there for? To display data.
That’s it.
4 Workflows are a succession of Business Rules
Follow the same principles! They do, but won’t think. Make Script Includes the brain of your Workflows.
But what about macros, widgets and pages?
Remember Client Scripts? Yeah, they are what Workflows are to Business Rules.
5 What’s with UI Actions?
Think of them as doorbells. You can hit a door bell. Does the door open cause of the doorbell? Not necessarily. Will the door open without it? Certainly not.
Use them as doorbells. Trigger actions without doing anything. Nothing to think about either.
6 Object Orientation – It’s a charm
Beauty of the cloud? You are not hosting the database. Loads of tables and relations take up too much space? None of your business. Utilize object orientation.
7 Object Orientation without Object Calisthenics
Try it. It’s like Buddhism but without the use of mediation. It works fine, but it is inefficient. And usually it prevents from achieving the cool stuff.
8 Draw a painting – visualize structures
If you cannot draw your architecture, don’t bother trying to explain it. Can’t explain your architecture? Well, overly complicated things for 500, please.
9 Read code – a lot
Things to learn from your past code and the code of other people:
- Better ways to do it
- How not to do it
Both important to improve. On a side note: Iterate your architecture. Rework it. The best way to improve is to learn from the past. Best way to do this is to solve issues from past projects.
10 It’s art – opinion is subjective and there is no definite best solution
Two key points here:
- Don’t let this prevent you from searching for the best possible solution.
- Even art can be objectively shit.
(courtesy Fabian@snowcommunity)
Comments
Post a Comment