Bounded Contexts

A Bounded Context is a key concept from Domain-Driven Design (DDD) that helps divide a large system into well-defined, independent modules, each with its own domain model, language, and business rules.

Importantly, DomusJS does not enforce DDD or bounded contexts, but it provides tools that make it easier to apply these patterns if you choose to follow them.

What is a Bounded Context?

A bounded context is a boundary around a specific domain or subdomain where certain terms, concepts, and rules have a precise meaning.

Inside this boundary:

Models are consistent and well-defined.
Outside this boundary, the same words might mean something different.

Example:

In an Auth Context, “account” refers to user credentials and permissions.
In a Billing Context, “account” refers to customer billing information.

Bounded contexts help avoid confusion and ensure clarity in large systems.

Why Use Bounded Contexts?

Bounded contexts are particularly useful when:

Your system grows large and complex.
Multiple teams are working on different parts of the system.
Different parts of the system evolve at different speeds or have different business requirements.

They allow you to: ✅ Reduce coupling between modules.
✅ Maintain clear ownership and responsibility.
✅ Evolve each context independently.
✅ Prevent semantic confusion between domains.

How Bounded Contexts Relate to DDD

Bounded contexts are part of strategic design in DDD.

You can apply them with or without adopting full DDD — they’re simply a smart architectural way to organize large systems.

DomusJS provides a modular foundation that makes it easy to apply bounded contexts, but it does not force you to use them.

Applying Bounded Contexts in DomusJS (Optional)

If you choose to apply bounded contexts in DomusJS, you can:

Create separate folders per context.
Register context-specific services and dependencies.
Keep domain logic encapsulated within each context.

Example structure:

/src/contexts/
  auth/
    application/
    domain/
    infrastructure/
  videos/
    application/
    domain/
    infrastructure/
  billing/
    application/
    domain/
    infrastructure/

Each context can have:

Its own commands, queries, events, and handlers.
Its own services and repositories.
Its own event subscribers and integrations.

DomusJS’s modular buses, DI container, and event system make this kind of architecture easy to support.

Advanced Topics

Context Mapping

Context mapping describes how bounded contexts interact.

Common patterns:

Shared Kernel → shared components between two closely related contexts.
Customer-Supplier → one context depends on the outputs of another.
Anti-Corruption Layer (ACL) → protects one context from leaking the models of another.

Integration Patterns

Bounded contexts communicate through:

Domain events → asynchronous, decoupled notifications.
APIs → synchronous communication with contracts.
Message queues → asynchronous job or event pipelines.

DomusJS supports event-driven communication via its Event Bus, including integrations with RabbitMQ, Google Pub/Sub, and more.

Strategic Design

Defining bounded contexts is not arbitrary — it should align with:

Business capabilities.
Organizational structure.
Domain expert language.

Poorly drawn boundaries can increase complexity rather than reduce it.

Important Reminders

Bounded contexts are optional — use them when they add value.
Avoid overengineering in small projects.
Keep communication between contexts explicit and well-defined.