From SaaS to Microservices: Understanding Bounded Contexts & Architecture Patterns

Professional Terms

IAAS: Infrastructure-as-a-Service

PAAS: Platform-as-a-Service

SAAS: Software-as-a-Service

Architecture Evolution

SAAS: Initially we built monolithic applications where multiple business functions were tightly coupled. As the business grew, we separated concerns using MVC, SSM, and layered architectures to decouple services.

PAAS: With growing business, we needed to extract subsystems but rebuilding each from scratch was costly. We adopted common technologies such as mesh, SOA, and micro‑services to isolate systems and reuse these technologies for rapid subsystem creation.

IAAS: When a service (e.g., order service) experiences high concurrency, a single server is insufficient. Deploying multiple servers across different OSes (Windows, Linux, macOS) requires abstraction layers like VMs, Docker, and Kubernetes to hide OS differences.

Bounded Context

BC and business: By dividing the business into sub‑domains (e.g., Order, Inventory), the same concept “product” can have different meanings—price and discount in the Order context, stock quantity and location in the Inventory context.

BC and technology: Different sub‑domains must be aggregated at the application layer. Synchronous calls may be used for order‑to‑inventory, while asynchronous messaging middleware is needed for other interactions.

Bounded Context Division Rules

Generally, start by considering team size; overly fine‑grained BCs can burden deployment and operations for small teams. After setting granularity, split by semantic relevance and functional relevance (business‑oriented vs. non‑business‑oriented).

Is a BC a Microservice?

Concept: A microservice is a deployable unit with its own technology stack, elasticity, and release cadence, essentially maintaining a single business capability.

Relationship: A BC represents a domain or module; multiple closely related BCs may reside in one microservice, or a high‑traffic domain may be split into several microservices for performance.

Four Boundaries of Domain‑Driven Design

1️⃣ Vision & Goal: Define project vision, problem space, core, generic, and supporting sub‑domains.

2️⃣ Solution Space: Bounded Contexts act as physical isolation layers.

3️⃣ Layered Architecture within a BC: Interface, Domain, Application, and Infrastructure layers are minimally coupled.

4️⃣ Aggregates: In the domain layer, aggregates ensure consistency and act as the smallest unit of isolation.

Clean Layered Architecture

The diagram shows that the domain layer is independent of any infrastructure or framework, containing only business logic. This separation enables easy swapping of the infrastructure layer and provides a clean interface for external web services.

Hexagonal Architecture

Active adapters (e.g., UI, CLI) act as input ports; passive adapters (e.g., databases, external services) act as output ports. All ports are interfaces, keeping the core application isolated from external implementations.

Onion Architecture

Building on the hexagonal model, the onion architecture further separates the inner business logic (application services, domain services, domain model) from outer layers, enforcing that dependencies point inward.

Summary

Domain‑Driven Design, combined with its four‑boundary approach, provides a solid foundation for decoupling domains, supporting both vertical business expansion and horizontal functional scaling.