Domain Driven Design - Concepts

Domain-Driven Design (DDD): Design the software around the business, not around the database or technology.

A domain is the business area your software is solving.

For example, if you are building an online casino:

Domain = Online Gaming / Casino

Inside that domain, you have business concepts such as:

• Player

• Game

• Game Session

• Bet

• Wallet

• Payment

• Reward

• Transaction

DDD says:

First understand these business concepts and their rules, then design your software around them.

Bounded Context

Context is the business area which is being solved. For each model, explicitly define the context in which it exists. There are no rules to creating a context, but it is important that everyone understands the boundary conditions of the context.

What are the business boundaries?"

For example, your casino platform could potentially be divided into:

                 Casino Platform

 ┌───────────────────────────┐
 │ Player Management         │
 └───────────────────────────┘

 ┌───────────────────────────┐
 │ Game Session              │
 └───────────────────────────┘

 ┌───────────────────────────┐
 │ Wallet / Financial        │
 └───────────────────────────┘

 ┌───────────────────────────┐
 │ Rewards                   │
 └───────────────────────────┘

 ┌───────────────────────────┐
 │ Game Provider Integration │
 └───────────────────────────┘

 ┌───────────────────────────┐
 │ Responsible Gaming        │
 └───────────────────────────┘

Each represents a potential Bounded Context.

Then you decide which contexts should become separate services based on factors such as:

• Business ownership

• Data ownership

• Scalability

• Deployment independence

• Team boundaries

• Transaction boundaries

• Change frequency

DDD = Understand the business → divide it into meaningful boundaries → create a domain model → keep business rules inside the domain → communicate between boundaries using well-defined contracts/events.

A Context Map is a high-level diagram that shows how different Bounded Contexts interact with each other.

Think of it as a map of your business systems and their relationships.

Bounded Context = boundary

Context Map = relationship between boundaries.

What is Proxy?

A proxy is simply an intermediary between a client and another server.

The proxy can:

• Forward requests

• Hide the destination

• Apply access rules

• Log traffic

• Cache responses

• Modify headers

• Control connections

Main Proxy Types

1. Forward Proxy → Client → Proxy → Internet — Acts on behalf of the client and controls/monitors outbound internet access.

2. Reverse Proxy → Client → Proxy → Server — Acts on behalf of backend servers and hides/protects them from clients.

3. Transparent Proxy → Client → Proxy → Internet — Intercepts traffic without requiring explicit proxy configuration on the client.

4. Caching Proxy → Client → Proxy → Cache/Internet — Stores frequently requested content and serves it faster from cache.

5. Web Proxy → Client → Web Proxy → Website — Specifically handles HTTP/HTTPS web traffic.

6. API Gateway → Client → API Gateway → Microservices — Specialized API reverse proxy providing routing, authentication, rate limiting, etc.

7. Service Mesh Proxy → Service A → Proxy → Proxy → Service B — Manages service-to-service communication such as mTLS, retries, timeouts, and traffic policies.

Easy memory trick

Forward Proxy   → protects/represents CLIENT
Reverse Proxy   → protects/represents SERVER
API Gateway     → manages APIs
Service Proxy   → manages SERVICE-to-SERVICE traffic
Caching Proxy   → caches CONTENT
Transparent     → intercepts WITHOUT client configuration

@Bulkhead limits the number of concurrent payment calls so a slow Payment Service cannot exhaust resources in the calling service. @CircuitBreaker monitors payment failures and temporarily stops calls when the dependency becomes unhealthy. Together they provide isolation and fail-fast behavior.