Bounded Context in Microservice

Concept: Bounded Context in Microservices Architecture

In microservices architecture, a bounded context refers to the clear boundaries that define the scope within which a particular service operates. It’s a concept from domain-driven design (DDD) that emphasizes the importance of defining explicit boundaries around different parts of a system based on their domain responsibilities.

Each microservice in a system should have a clearly defined bounded context, which includes:

• Domain Knowledge: The microservice should have a clear understanding of the domain it serves and the specific business capabilities it provides.
• Data Ownership: Each microservice is responsible for its own data and should encapsulate it within its boundary. This helps prevent data coupling between services.
• Language and Models: Within its bounded context, a microservice may use its own language, models, and terminology that make sense within its specific domain. This can differ from other microservices within the same system.
• Functional Boundaries: The boundaries define what functionalities the microservice encapsulates and exposes to other parts of the system. This helps in ensuring that each microservice is cohesive and focused on a specific aspect of the overall system’s functionality.

By defining clear bounded contexts, microservices can be developed, deployed, and scaled independently, allowing for better agility, scalability, and maintainability of the system as a whole. Additionally, it helps teams focus on developing services that align with specific business needs without being overly constrained by the complexities of the entire system.

Let’s consider a simple e-commerce system with two bounded contexts: OrderService and ProductService.

Bounded Context Illustrated Example

// OrderService.cs

public class OrderService
{
    private readonly ProductService _productService;

    public OrderService(ProductService productService)
    {
        _productService = productService;
    }

    public void CreateOrder(int customerId, List<int> productIds)
    {
        // Business logic for creating an order
        foreach (int productId in productIds)
        {
            ProductDetails productDetails = _productService.GetProductDetails(productId);
            // Do something with product details
        }
        // Continue with order creation logic
    }

    public OrderDetails GetOrderDetails(int orderId)
    {
        // Retrieve order details from the database
        return null;
    }
}

// ProductService.cs

public class ProductService
{
    public ProductDetails GetProductDetails(int productId)
    {
        // Retrieve product details from the database
        return null;
    }

    public List<Product> SearchProducts(string query)
    {
        // Search for products based on a query
        return null;
    }
}

In this example, OrderService and ProductService represent two separate microservices, each with its own bounded context.

OrderService focuses on managing orders. It has methods for creating orders (CreateOrder) and retrieving order details (GetOrderDetails).

ProductService focuses on managing products. It has methods for retrieving product details (GetProductDetails) and searching for products (SearchProducts).

Each microservice encapsulates its own domain logic and data, allowing them to evolve independently. They communicate with each other via APIs or messaging, and their boundaries ensure that changes within one context have minimal impact on the other.

Bounded Context Violation

The below example demonstrates the violation to the bounded context. Realistically, if the design is correct at the beginning as each services own its database, this will not ever happen.
By allowing the OrderService to directly modify product entities without using a separate ProductService, violating the bounded context principle. Let’s illustrate this:

// OrderService.cs

public class OrderService
{
    public void CreateOrder(int customerId, List<int> productIds)
    {
        // Business logic for creating an order
        foreach (int productId in productIds)
        {
            // Violation: OrderService modifies Product entities directly
            Product product = Database.GetProductById(productId);
            product.ReservedQuantity++; // Increase reserved quantity
            // Update product in the database
            Database.UpdateProduct(product);
        }
        // Continue with order creation logic
    }

    // Other OrderService methods...
}

In this example:

• The OrderService directly modifies the Product entity’s ReservedQuantity property during order creation without using a separate ProductService.
• This violates the bounded context principle because OrderService is directly interacting with the domain entities of the Product context, leading to tight coupling between the Order Management and Product contexts.

Such a violation could lead to issues such as:

• Increased coupling: Changes in the Product entity’s structure might affect the OrderService, and vice versa.
• Reduced autonomy: Services become less independent, hindering their ability to evolve and scale separately.
• Potential inconsistencies: Modifying product entities from the OrderService may lead to inconsistencies in data and business logic between the Order Management and Product contexts.

To maintain clear boundaries between bounded contexts, it’s essential to ensure that each service encapsulates its own domain logic and data entities, communicating with other services through well-defined interfaces rather than direct modifications to entities in another context.