codingwithalex

Design Patterns: A Powerful Tool When Used Correctly – A Deep Dive Into Chain of Responsibility with Domain-Driven Design (DDD) and TypeScript

Alex Silva -

Design patterns are a powerful tool for software developers, providing a proven and efficient way to solve common design problems. However, using them correctly is key to leveraging their full potential. One of the major challenges many developers face is understanding when and how to apply design patterns. Misusing these patterns can lead to over-engineered and confusing code.

This post will walk through a practical example using the Chain of Responsibility design pattern to handle payment gateway configurations in a microservices architecture. We'll also dive into Domain-Driven Design (DDD) principles, all illustrated with TypeScript. This real-world example involves dynamically choosing a primary payment gateway and its fallback structure based on configurations, all while allowing for future changes without code modifications.

Why Understanding Design Patterns is Crucial

Before diving into the example, let’s first address a key misconception: design patterns are not a one-size-fits-all solution. Some developers mistakenly apply patterns without fully understanding their purpose or context. This can lead to overly complex systems that are hard to maintain or modify.

The Chain of Responsibility pattern is often misunderstood. Some developers use it to chain too many responsibilities or apply it in scenarios where it is unnecessary. Understanding its proper use case is crucial to making the most of this pattern. The Chain of Responsibility is most appropriate when you need to pass a request along a chain of handlers, where each handler can either process the request or pass it on to the next handler.

The Problem: A Dynamic Payment Gateway Selector

Let’s say we are developing a payment microservice in a microservices architecture. One key requirement is the ability to dynamically select the primary third-party payment gateway and seamlessly fall back to other payment gateways if the primary one fails.

Requirements:

  1. The payment gateway should be selected based on configuration.
  2. The fallback structure should be dynamically configurable without requiring code changes.
  3. It should allow for future extensibility if additional payment gateways are added later.

Solution:

To meet these requirements, we will implement the Chain of Responsibility pattern to manage the flow of payment gateways. We'll also incorporate Domain-Driven Design (DDD) principles to ensure that the system is well-structured, maintainable, and future-proof.

Chain of Responsibility in a Payment Gateway Microservice

What is Chain of Responsibility?

The Chain of Responsibility pattern allows you to send a request through a series of handlers. Each handler can either process the request or pass it along to the next handler in the chain. This decouples the sender of the request from the handlers, making it flexible and extensible.

In our payment gateway example, each handler in the chain will represent a different payment gateway. If the first handler (primary payment gateway) fails, the request is passed along to the next handler (fallback gateway), and so on.

Domain-Driven Design (DDD) Principles

In this example, we’ll follow Domain-Driven Design (DDD) principles, which help ensure that the business logic is organized around the core domain of the application. In this case, our core domain is payment processing, and we will model it by defining core entities, value objects, and services in a way that reflects the domain.

Key DDD Concepts:

  1. Entities: Objects that have a unique identity, such as PaymentTransaction.
  2. Value Objects: Immutable objects that have no identity, like a PaymentAmount.
  3. Domain Services: Encapsulates domain logic that doesn’t naturally belong to an entity or value object, such as selecting the payment gateway.

Step-by-Step Example: Implementing a Payment Gateway Microservice

1. Define the Payment Gateway Interface

We’ll start by defining a simple interface that all payment gateways must implement. Each gateway should have a method to process the payment.

interface PaymentGateway {
    processPayment(amount: number): boolean;
}

2. Create Payment Gateway Handlers

Next, we’ll create individual payment gateway handlers that implement the PaymentGateway interface. Each handler will decide whether to process the payment or pass it along the chain.

class PrimaryPaymentGateway implements PaymentGateway {
    private nextHandler: PaymentGateway | null = null;

    setNext(handler: PaymentGateway): void {
        this.nextHandler = handler;
    }

    processPayment(amount: number): boolean {
        // Simulate payment processing
        const success = Math.random() > 0.5;
        console.log("Primary Gateway:", success ? "Success" : "Failure");

        if (!success && this.nextHandler) {
            return this.nextHandler.processPayment(amount);
        }

        return success;
    }
}

class FallbackPaymentGateway implements PaymentGateway {
    processPayment(amount: number): boolean {
        const success = Math.random() > 0.5;
        console.log("Fallback Gateway:", success ? "Success" : "Failure");
        return success;
    }
}

In this setup:

  • PrimaryPaymentGateway attempts to process the payment first. If it fails, it passes the request to the next handler (the fallback gateway).
  • FallbackPaymentGateway acts as a backup when the primary gateway fails.

3. Build the Payment Processing Chain

Now we need to dynamically configure the payment chain based on the configuration.

class PaymentProcessor {
    private firstHandler: PaymentGateway;

    constructor(config: { primary: PaymentGateway, fallback: PaymentGateway }) {
        this.firstHandler = config.primary;
        config.primary.setNext(config.fallback);
    }

    process(amount: number): void {
        const success = this.firstHandler.processPayment(amount);
        if (!success) {
            console.log("All payment gateways failed.");
        }
    }
}

This class allows you to create a chain based on the configuration. You can easily swap out the primary or fallback payment gateways without modifying the business logic.

4. Implementing Configuration-Driven Selection

To make our system even more dynamic, we can fetch the configuration (e.g., from a database or environment variables) and adjust the payment gateway chain at runtime.

const config = {
    primary: new PrimaryPaymentGateway(),
    fallback: new FallbackPaymentGateway(),
};

const processor = new PaymentProcessor(config);
processor.process(100);  // Try to process a payment of 100 units

Why Chain of Responsibility?

The Chain of Responsibility design pattern shines in scenarios like this because it decouples the client (the payment service) from the exact implementation of how payments are handled. If you need to add another fallback gateway in the future, all you need to do is add another handler to the chain without modifying existing handlers.

Benefits:

  • Flexibility: New payment gateways or fallback mechanisms can be added without modifying existing code.
  • Separation of Concerns: Each payment gateway is responsible only for processing payments, without knowledge of the other gateways.
  • Extensibility: You can easily add new gateways to the chain.

Integrating Domain-Driven Design (DDD)

Let’s briefly talk about how Domain-Driven Design (DDD) concepts are used here to create a clean architecture.

Entities and Value Objects:

  • PaymentTransaction could be an entity representing a single payment attempt, holding information like the payment amount, status, and timestamp.
  • PaymentAmount could be a value object, representing the exact amount and currency.

Domain Services:

  • The PaymentProcessor is an example of a domain service. It encapsulates business logic that doesn’t belong to a specific entity but is crucial for the domain.

Conclusion: Design Patterns Are Powerful, But Use Them Wisely

Design patterns like Chain of Responsibility are incredibly useful when applied in the right context. As seen in the payment microservice example, this pattern allowed us to create a flexible and extensible system for managing multiple payment gateways and fallbacks.

However, it’s essential to understand when and how to apply these patterns. Misapplying design patterns can result in overly complicated systems that are difficult to maintain. By combining patterns like Chain of Responsibility with Domain-Driven Design (DDD) principles, you can create systems that are both robust and adaptable to future changes.