Integration & Implementation of various third-party services is by its own a pain, especially when we have to deal with different distributed systems and technologies. For every implementation, we want to have specific standards for our product giving emphasis on software quality and more specific over stability, security, reliability, performance efficiency & maintainability of the code. Thus we have adopted some rules which we follow during the design and implementation of a Service Manager.
Usage of the Service Managers SDK is necessary
SDK's LogsHelper is the way to go in order to Log Requests, Responses, Exceptions & general Messages
SDK's LogTracer is the way to go in order to Log the flow correctly
SDK's Logging mechanism is the way to go in order to have a unified logging & logging format.
SDK's filters are necessary
SDK's configuration if necessary
Successful Results to BSS MUST be made via SuccessResult
Error Results to BSS MUST be made via the ErrorResult
Controller, is nice to have it separated into various files according to the implemented section. Thus, the partial class is highly recommended and encouraged.
Use clean Code. Coding lines should be separated by at least one empty line if they are not in the same context. Example :
counter = 10;
name = "I am a string";
for (int i = 0; i < counter; i++)
Methods within a Class must have a least one empty line between them
Avoid using Abbreviations.
Method names & variables must mean something
Private, Protected & Public methods and fields must be grouped in the same context. The preferred way is to write the Private, Protected and in the end the Public
Usage of interfaces is encouraged
Code must be aligned and in general organized so that it can be easy on the human eye
Unnecessary variables (fields, properties) & methods must be removed from the code
Comments should exist especially during the implementation of a complex flow or during the implementation of an algorithm. But we must not overdo it with comments.
Code must be implemented taking into account security & performance
If we have to decide between performance and security, security gets the priority.
Do not make memory leaks
Do not make deadlocks
Re-entrant methods are the way to go
Thread-safe methods are the way to go
The usage of strong data types is encouraged.
Dynamic data types need to be documented either via comments or documentation
Logging is necessary and required on EVERY transaction is made with another system
All exceptions MUST be caught, regardless of the level, and get logged
Errors MUST be logged
Following the S.O.L.I.D. principles is the way to go
The usage of design patterns is encouraged. Some of the design patterns we use are: Dependency Injection, Strategy, Singleton (do not overdo with this), Repository, Proxy
BSS & Third parties must be separated and work together as modules. This means that for the communication with the BSS responsible is the controller while for the communication with the third party service the specific Manager will be responsible. Thus, we can have both specific integration tests and separated context. The controller will use the Manager in order to communicate with the third party.
Usage of static methods and variables ARE NOT encouraged unless they are needed by the implementation, for example for custom internal caching, singleton, etc.
The implementation MUST take into account multiple concurrent requests and multi-threaded environment.
There are two kinds of Integration Tests. The ESOTERIC Integration Tests, which will test the Manager and the End To End Integration Tests which will simulate the BSS requests till the third party Endpoint and back.
Tabs should be replaced by 4 spaces
While developing a Service Manager, we must have in mind that debugging must be (if possible) from the Logging mechanism. Everything starts and ends to the Logs then we need to see the code in order to verify & provide a solution.