Service Managers Development Guide

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.

 

Coding Style & Rules

Object Name

Notation

Underscores

Object Name

Notation

Underscores

Class name

Pascal Case

Avoid if possible

Method name

Pascal Case

Avoid if possible

Method arguments

camel Case

No

Local variables

camel Case

No

Member variables (fields)

camel Case

Yes (they must start with an underscore)

Properties

Pascal Case

No

Delegate name

Pascal Case

No

Enumeration name

Pascal Case

No

Constants

Pascal Case

No



  • 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 :

    int counter;
    string name;

    counter = 10;
    name = "I am a string";

    for (int i = 0; i < counter; i++)
    {
        Console.WriteLine(name);
    }

     

     

  • 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.