Clean Code Architecture

When we design a system we tend to follow some architectural pattern. Architecture patterns help us to design systems that can be easily scalable and maintainable. There are different types of software architecture patterns but for this article, we are going to discuss Clean Code Architecture pattern. In the last few years, clean code architecture has become so popular. Let’s begin with its history. Do you know who introduces Clean code architecture? Robert C. Martin who also know as Uncle Bob introduce Clean Code Architecture. Clean Code Architecture divides the system into different layers which provide the following benefits.

• Testable: Business rules can be easily testable without any dependencies on UI, Database, or any external system.
• Independent UI: UI can be changed at any time without affecting business logic.
• Independent Database: The business rule shouldn’t depend on the database. you can change the database anytime to SQL or Oracle or Mongo DB.
• Independent of the external system: Business rules shouldn’t know about any external system like your payment gateway i.e you can change your payment gateway from one provider to another anytime without changing your business logic.

In Clean Code Architecture divide system into three-layer

• Presentation/Infrastructure Layer
• Application Layer
• Domain Layer

In Clean code architecture, we have a dependency rule which means our code dependencies can only point inwards. Nothing inner circle knows about the outer circle.

Presentation/Infrastructure layer: Presentation layer is one from where the user or other system going to interact with our system like Controls, gRPC services, APIs, Event consumers, CLI command. The presentation layer shouldn’t care about application logic. Its transfers the request to the application layer and covert response from the application layer to the user.

Infrastructure layer contains the actual implementation of the services or class where you are going to connect with an external system like database, adapters, other microservice, etc.

Application layer: Application layer consist of Use cases or Workflow services. Those services orchestrate the steps required to fulfill the commands imposed by the client. Use cases are the list of the action which needs to perform by an application like creating user, submit an order or take payment, etc. You can implement CQRS pattern to the application layer which is basically commands and queries. The application layer performs certain business logic and transfers the request to the domain layer.

Application layer is independent of infrastructure and data access concerns. You can define the interface in the application layer but the actual implementation should be at the infrastructure layer.

Domain layer: Domain layer contains application business rules. The domain layer consists of Entity, Aggregates, and Domain Event. An entity can be an object with methods or can be a set of data structures and functions. Aggregates combine multiple entities into a single. Domain events are used to notify the same domain that something happens to the domain.

Please find https://github.com/nibro7778/CleanCodeArchitecture code which demonstrate Clean Code Architecture

I have used Order domain to demonstrate the Clean Code Architecture.

• Order.Api (Presentation Layer)
  • Contains only OrderController
  • Only reference to Order.Application
• Order.Application (Application Layer)
  • Contains use cases like SubmitOrder, GetOrder
  • Each use cases contains indpendent each other. Also, you can notice I have used CQRC Pattern.
  • Only reference to Order.Domain
  • Order.Application layer has contract IOrderRepository actual implementation is in Order.Infrastructure
• Order.Domain (Domain Layer)
  • Contains Order entity, Domain events and business rules
  • Domain layer shouln’t reference to any other layer
• Order.Infrastructure (Infrastructure)
  • Order repository implementation
  • Only reference to Order.Application

The main rule of clean architecture is that code dependencies can only move from the outer levels inward. Code on the inner layers can have no knowledge of functions on the outer layers.

References:

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

https://www.ssw.com.au/rules/rules-to-better-clean-architecture

https://github.com/Sairyss/domain-driven-hexagon

Adapter Design Pattern

In my last post, I discussed one of the creational design patterns now will discuss the adapter design pattern which is a structural design pattern.

Before moving further if you would like to understand the basic concept and type of design pattern refer to my previous post on Singleton Design Pattern in which I discuss basic concept and type of design pattern very high level. So that will help you to get a better understanding of the adapter design pattern.

As per the gang of four definition adapter design pattern “Match interfaces of different classes”

In software engineering adapter pattern allows the incompatible class to interact with the existing class by converting the interface of one class into an interface expected by the client. Adapter pattern help to reuse the existing functionality as it is a bridge between two incompatible interfaces.

Adapters coverts the interface of one class into an interface a client expects

Let’s take a real-life example, Travelling internationally with electronic devices has become so common and the power plug and socket standard are different in different countries so you need an adapter to convert the shape of your home power plugs to the shape of the outlets in the region of the world you are traveling to.

Now let’s take one technical example, your current application work with XML data and now you are going to plug in some external APIs to your application but that external APIs work with JSON data only. In this situation, you can either rewrite your code to support JSON data or you can ask third-party APIs providers to change their code to support XML. The first option required lots of effort and regression testing as you are going to change your existing code and the second option might be not possible as they are not supporting XML data.

To solve this problem you can create an adapter interface that is responsible to convert one type of object to an incompatible type of object. In our scenario, we can create XML to JSON adapter which will convert XML data to JSON data, and then it will pass to third-party APIs. It is also possible to create a two-way adaptor that converts the call in both directions. following diagram shows how we can implement XML to JSON adapter in our example

Let’s take one more example in which we will going to implement the actual code and using that code we will try to understand the adapter design pattern. you can find same code from Github: Adapter Design Pattern Example

Scenario: We have a product display service that can be display product from two different sources one using file and another by calling the vendor API

So, for the above scenario, we are going to create an IProductSourceAdapter Interface which has Task<IEnumerable<Product>> GetProducts(); So, the client will use this method to get the list of products.

Also, we are going to implement two different classes. One class for file FileSource which get the product from a file using GetProductFromFile method and another for API VendorApiSourcewhich get products by calling Vendor API under GetProducts method

Now, we are going to implement FileSourceAdapter which create an instance of ​​FileSource and delegate the call to FileSource.GetProductFromFile(_filePath)

In the same way, we are going to implement VendorSourceAdapter which create an instance of VendorApiSourceand delegate the call to VendorApiSource.GetProducts(_clientApiUrl)

Now, here our client ProductDisplayService inject IProductSourceAdapterwe don’t care about which particular implementation it is. we will get this information based on the type that gets injected.

• Step 1: Client which has existing business logic.
• Step 2: Client Interface describes a protocol that other classes must follow to be able to collaborate with the client code.
• Step 3: Service has its own logic. The client can’t use this class directly because it has an incompatible interface.
• Step 4: Adapter is receiving a call from the client via client interface and translate calls to the service class

Adapter design pattern follows Single responsibility principle as each service has its own logic and only responsible for one thing like FileSource getting a product from a file only. Adapter design pattern also follows the Open-Closed principle as you can bring a new type of source without breaking the existing client code.

Also, you can find source code which demonstrate above example from following github link

https://github.com/nibro7778/adapter-design-pattern

Hope you’ll like it!

Singleton Design Patterns

Before discussing singleton design pattern let me give you some basic background of design pattern and its history

The idea of design pattern was picked by four authors: Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm, very well known by the Gang of Four where they applied a concept of typical programming. They came up with 23 design pattern for solving various real-life problems of object-oriented design.

A design pattern is one kind of recipes book to deliver delicious and tasty programming dishes 😉 A Design pattern act as a template which can be applied to the real world problem

Writing a code using design pattern makes your code more reliable, scalable and maintainable

There are 3 type of design pattern

• Creational
• Structural
• Behavioral

Creational: This design pattern gives you the functionality of object creation and initialization based on different cases. most popular creational design pattern are Factory, Singleton

Structural: This type of design pattern is responsible for building simple and efficient class hierarchies and a relation between different classes. for example Adapter, bridge

Behavioural: This design pattern deals with communication between classes and objects. for example Chain of Responsibility, Command, Interpreter etc

Singleton Design Pattern

Singleton design pattern is a creational design pattern which let you ensure that only single object is created for a particular class. All further references to the class are referred to this object.

Now, you think then what is different between static and singleton. the main difference between those two is singleton provide you object whereas static classes provide you with a static method. Singleton can implements interfaces, inherit from other classes and it is aligned with the object-oriented concept. Also, a singleton object can be passed to other methods as a reference whereas a static object cannot be passed as a reference.

For implementing singleton pattern to your code you must consider two common steps

1. Making default constructor as a private so that it cannot be instantiated outside of the class.
2. Create public creator method, which will create an object using a private constructor and save it on a static variable. so whenever any user requested for the object using public creator method it will return cached object from a static variable.

Top level view of a singleton design pattern class diagram

Following is sample code which ensures you only one object of the class is created and provide you access to that object using GetInstance() method.

public class Singleton {
        /// <summary>
        /// Static field to stored instance of the singleton class
        /// </summary>
        private static Singleton _instance;

         /// <summary>
         /// Private construct to restrict user to instance outside the class
         /// </summary>
         private Singleton() { }

         /// <summary>
         /// GetInstance method which create new instance if its null, and return instance  
         /// </summary>
         public static Singleton GetInstance => _instance ?? (_instance = new Singleton());
}

Following are some of the example of a real-world scenario where we can use singleton design pattern

• Logging management
• Device management
• File management
• Application configuration management
• Cache management
• Session-based shopping cart management

I have implemented a small project which demonstrates how we can use the singleton pattern for Logging to file or to external resources. find below git repository link for this.

Github: Singleton Pattern Example

Circuit Breaker Design Pattern

Most of the enterprise application uses external services to make an external operation like sending Email or SMS to send notification or external API, external resources to add functionality to our application. Whenever we are making a call to those external services, there may be a chance that those services are down. Our application should be prepared to handle that kind of scenario. We can handle this kind of scenario using retry pattern but retry pattern assumes that external service is available and continues to make a request

The circuit breaker pattern has different than a retry pattern. The circuit breaker prevents an application to perform an external services call that is likely to fail.

This pattern has three operation state:

• Close state
• Open state
• Half Open state

Close State: Operation are executed as usual (whenever we are making the first call to the external services at the time it will be in the closed state)

•  If a call to external service fails: The failure count is incremented and an OperationFailedException is thrown. If the failure count exceeds the threshold, the circuit breaker trips into the “open” state.
• If a call to external service succeeds: if calls succeed before the threshold is reached, the failure counter is reset and operation are executed as usual

Open state: whenever circuit breaker is in open state all calls to the external services will fail and In this state, it will not make an actual call to the external services instead of it will throw an exception OpenStateException. A timeout is started when the circuit breaker trips.

Once the timeout is reached, the circuit breaker enter into the half state

Half state: In “half state” circuit breaker allows one operation to execute.

•  If a call to external service fails: the circuit breaker re-enter into open state and timeout is reset.
• If a call to external service succeeds: circuit broker enters into close state and operations are executed as usual

Below sample code will be used to implement circuit breaker with Polly. Here we are creating the Polly handler for circuit breaker when WebException occurred during an external call. This policy will break the circuit with two consecutive exceptions of WebExcption type and the circuit will remain a broker

//creating policy object for handle webexception using circuit breaker
Policy policy = Policy.Handle() 
  .CircuitBreaker(
    exceptionsAllowedBeforeBreaking: 2, 
    durationOfBreak: TimeSpan.FromMinutes(1) );

//To Excute external service call
policy.Execute(action); 

For a better understanding of the circuit breaker using Polly, you can check it out on below link

https://github.com/App-vNext/Polly/wiki/Circuit-Breaker

I have also created sample repo in GitHub to provide you a basic understanding to implement circuit breaker with Polly nuget package. GitHub demo-application-circuit-breaker

Secure your API with API key and HMAC authentication

This article provide you basic information about API Key and HMAC authentication and how we can implement API Key and HMAC authentication into our Web API

What is HMAC Authentication?

HMAC is message authentication code which is generated using a hash function in combination with shared secret key (API Key) and public Key (APP Id).

A server will first time provide APP Id (shared public key) and API key (shared secret key) to a consumer at the time of registration, Client will generate HMAC using APP Id and API key and then the consumer sends that HMAC to a server in the request header. At the server, side server will regenerate HMAC using same APP Id and API key, once the hash generates server will respond to compare hash sent by the client along with regenerated HMAC, If they match then server consider the request as authenticated and process further.

How to create HMAC and send an authorization header to API server?

Consumer needs to generate string by combining APP ID, HTTP Method, request URI, request timestamp, nonce and base 64 string which contains request payload then client will hash this large string using hashing algorithm (SHA256) using shared secret key (API Key), which will create unique hash signature for the request.

The signature will be sent via Authorization header using custom schema. Following is an example of a custom schema.

[Authorization: xyz APPId:Signature:Nonce:Timestamp]

APPID: Public key which shared with consumer

Signature: Hashed string using hashing algorithm (SHA256)

Nonce: It is arbitrary number or string

Timestamp: Number of seconds since 1^st Jan 1970 (UNIX time)

Once the server receives a request from the client, it will regenerate HMAC and compare it with authorization header HMAC, if they are equal then the server will consider this call as an authenticated and process the request.

There are some more benefits of having API Key which is explained below

API key is a unique value which is assigned to API consumer. A consumer will use API key whenever they make an API call. A server will provide shared private secret (API Key), the consumer needs to store the API key securely and never shared it with other parties.

API key is a new way of authorizing users. API key uses secret token which will send with a request to authorize API request call.

API consumer needs to pass API Key in a request and API server will validate API key to allow grant access to resources.

API key restricts access to API methods or all methods to a particular group of people. API key doesn’t use to identify users, it mostly uses for identifying a group of people or company. Most of the company now a day uses API key by selling their API and then tracking who’s using the thing for billing purposes.

API key also uses to filter the log and to find out usage pattern in your API traffic.

You can differentiate API key by public or private. You can share public API key to other to allow them to get limited information about your API whereas private key is about your use only.

 

SQL Server Service Broker

Service Broker is a process of sending and receiving asynchronous messages by using T-SQL commands.

It’s similar to other queuing technologies. Messages can be sent to a queue in the same database as the sender, to another database in the same SQL Server instance, or to another SQL Server instance either on the same server or on a remote server.

Data is usually sent as an XML data and you can also encrypt your message during transmission

As per my point of view Service broker can use to achieve following functionality

1. Asynchronous process
2. Decoupling execution from caller
3. Distributed Server-Side Processing

Asynchronous provide you event-driven model. Asynchronous processes do not depend on other process. Its work independently on different threads simultaneously.

Decoupled execution allows components to remain completely autonomous, unaware of each other and process by itself.

Large application use multiple SQL Server to manage client application, Service broker can be used to communicate and pass data between those multiple SQL Server

Real world example where you can use SQL service broker

• In database we use trigger to perform particular task after insert, update or delete. Those task will execute synchronously and if trigger has lots of T-SQL statement then it’s become time consuming work. So in this situation we can use service broker for asynchronous execution.
• Service broker doesn’t support publish-subscribe framework but you can play around service broker component to implement publish-subscribe pattern
• Ordering web application could use service broker on the server side to send information to different database that might contain data related to inventory, customer and update other database based on message.

There are two part of the service broker end to end process

1. Configuring the Service broker component
2. Sending and Receiving Messages

Configuring the Service Broker

Below image help you to find out service broker component on SQL Server

Service broker components need to configure to start working on service broker. Below are step by step guideline to configure service broker component.

1. Enable the Service Broker on the database
2. Create valid Message Types.
3. Create a Contract for the Conversation.
4. Create Queues for the Communication.
5. Create Services for the Communication.

1. Enabling Service Broker

Service broker is database level feature. It is not a SQL server instance level feature so that you need to enable it on the particular database on which you want to sue service broker feature.

Following is SQL Query which can be used to enable service broker on particular database

USE master
ALTER DATABASE [DatabaseName]
SET ENABLE_BROKER;

To verify whether service broker is enable or not on particular database you can use following query

SELECT is_broker_enabled FROM sys.databases  
WHERE name = [DatabaseName]

Following screenshot can also useful to know whether service broker is enable or not

2. Create Valid Message Types

Message Types need to specific to send and receive messages. The initiator and the target will use the same message type to communicate between them. You can create as much as message type in database that participant in a conversation.

Following query will use to create Message Type of service broker

USE [DatabaseName]
CREATE MESSAGE TYPE [MessageTypeName]
VALIDATION=WELL_FORMED_XML;

Validation can be specified upon the content of the Message Type, most commonly used validation is WELL_FORMED_XML

3. Create a Contract for the Conversation

Service broker requires a contract to send and receive message. It also define Message type that is used during service broker conversion and also define which side of conversion can be send a message.

Following T-SQL statement used to create contract

USE [DatabaseName]
CREATE CONTRACT [ContractName] ([MessageTypeName] SENT BY INITIATOR);

4. Create Queues for the Communication

Service broker queue used for storing message during sending and receiving. There should be two queue one sender and other for receiver

Following T-SQL statement used to create queue one for initiator and one for target

USE [DatabaseName]
CREATE QUEUE [InitiatorQueueName];
CREATE QUEUE [TargetQueueName]; 

5. Create Services for the Communication

Service broker Services route the message to particular queue. When the initiator or the target send a message, it will route the message to specific queue. So, we will define each service with their appropriate queue.

Following T-SQL statement is used for create service for initiator and target

USE [DatabaseName]
CREATE SERVICE [InitiatorServiceName]
ON QUEUE [InitiatorQueueName] ([ContractName]);
CREATE SERVICE [TargetServiceName]
ON QUEUE [TargetQueueName] ([ContractName]); 

Sending and Receiving Messages

Once service broker is setup on you SQL server now you can send message between initiator and target queue using service broker component

For sending message to target you need to first determine the service and contract then prepare message and send the message.

Following T-SQL statement is used to send message to receiver queue

Determine service and contract using @Dialog on initiator side and send message

DECLARE @Dialog UNIQUEIDENTIFIER
BEGIN DIALOG CONVERSATION @Dialog
FROM SERVICE [InitiatorServiceName]
TO SERVICE [TargetServiceName]
ON CONTRACT [ContractName]
WITH ENCRYPTION = OFF

DECLARE @Message NVARCHAR (128)
SET @Message = ‘Hello World’;
SEND ON CONVERSATION @Dialog
MESSAGE TYPE [MessageTypeName] (@Message)

Receive Message

RECEIVE CONVERT (NVARCHAR (MAX), message_body) AS Message
FROM [TargetQueueName]

SQL Example: Send and Receive “Hello World” service broker example

--------------------------------------------------------------------------------------------------------------------
 -- This example configure service broker and performing sending and receiving “Hello World” message
 -------------------------------------------------------------------------------------------------------------------
CREATE DATABASE SBHelloWorld
GO
USE SBHelloWorld
GO
-------------------------------------------
 -- Configure service broker
--------------------------------------------
-- 1. Enable the Service Broker on the database
ALTER DATABASE SBHelloWorld SET ENABLE_BROKER
GO
-- 2. Create valid Message Types
CREATE MESSAGE TYPE SBMessageTest VALIDATION = NONE
GO
-- 3. Create a Contract for the Conversation
CREATE CONTRACT SBContractTest (SBMessageTest SENT BY INITIATOR)
GO
-- 4.a. Create Sender Queues for the Communication
CREATE QUEUE SBSenderQueueTest
GO
-- 4.b. Create receiver queue for the communication
CREATE QUEUE SBReceiverQueueTest
GO
-- 5.a. Create sender services for the communication
CREATE SERVICE SBSenderServiceTest ON QUEUE SBSenderQueueTest (SBContractTest)
GO
-- 5.b. Create services for the communication
CREATE SERVICE SBReceiverServiceTest ON QUEUE SBReceiverQueueTest (SBContractTest)
GO

------------------------------------------------------------
-- Send and receiver message over service broker
------------------------------------------------------------

DECLARE @SBDialogTest uniqueidentifier
DECLARE @Message NVARCHAR(128)
BEGIN DIALOG CONVERSATION @SBDialogTest
FROM SERVICE SBSenderServiceTest
TO SERVICE 'SBReceiverServiceTest'
ON CONTRACT SBContractTest
WITH ENCRYPTION = OFF

-- Sending Message
SET @Message = N'Hello World';
SEND ON CONVERSATION @SBDialogTest MESSAGE TYPE SBMessageTest (@Message)
-- View messages from Receive Queue
SELECT CONVERT(NVARCHAR(MAX), message_body) AS Message FROM SBReceiverQueueTest
GO
-- Receive Message
RECEIVE TOP(1) CONVERT(NVARCHAR(MAX), message_body) AS Message FROM SBReceiverQueueTest
GO
-- Drop database
USE master
GO
DROP DATABASE SBHelloWorld
GO

Some useful information that will help you out while working on service broker

—- Checking out queue
SELECT TOP 1000 *, casted_message_body =
CASE message_type_name WHEN ‘X’
THEN CAST(message_body AS NVARCHAR(MAX))
ELSE message_body
END
FROM [QueueName] WITH(NOLOCK)

—- Checking out transmission queue
SELECT * FROM sys.transmission_queue

 

Service Broker uses a transmission queue as a holding area for messages. Outgoing messages are added to the transmission queue in the database that sends the message. The message remains in the transmission queue until the destination has acknowledged receipt of the message.

References:

• Microsoft TechNet
• SQL Authority with pinal dave