Bounded Contexts

// ── Order context — cares about fulfilment ──────────────────────
package com.example.fulfilment.domain;

@Entity
public class Order {
    private String orderId;
    private String warehouseId;       // fulfilment-specific
    private List<PickItem> pickList;  // fulfilment-specific
    private ShippingLabel label;      // fulfilment-specific
    private FulfilmentStatus status;  // PICKING, PACKED, SHIPPED
}

// ── Finance context — cares about billing ────────────────────────
package com.example.finance.domain;

@Entity
public class Order {
    private String orderId;
    private BigDecimal   netAmount;        // finance-specific
    private BigDecimal   taxAmount;        // finance-specific
    private String       invoiceId;        // finance-specific
    private RevenueStatus revenueStatus;   // DEFERRED, RECOGNISED
}

// Same concept, different bounded contexts → different models
// Communication: Fulfilment publishes OrderShippedEvent
//                Finance subscribes and recognises revenue

// Anti-Corruption Layer — translates external model to local model
// Fulfilment service consumes Order events from Order service
// but translates them to Fulfilment's own domain model

@Component
public class OrderEventTranslator {

    // Order service publishes: {"orderId":"123","lineItems":[...],"shippingAddress":{...}}
    // Fulfilment model needs: PickList with warehouseLocations

    public FulfilmentOrder translate(OrderPlacedEvent externalEvent) {
        // ACL: maps external schema → local domain model
        List<PickItem> pickItems = externalEvent.getLineItems().stream()
            .map(item -> PickItem.builder()
                .sku(item.getProductSku())
                .quantity(item.getQuantity())
                .warehouseLocation(warehouseService.locate(item.getProductSku()))
                .build())
            .collect(Collectors.toList());

        return FulfilmentOrder.builder()
            .orderId(externalEvent.getOrderId())
            .pickList(pickItems)
            .status(FulfilmentStatus.PENDING)
            .build();
    }
}

// Signs of a well-bounded service:
// ✅ Owns its database — no other service reads/writes its tables directly
// ✅ Can be deployed independently without coordinating with other teams
// ✅ Has a small, stable API surface (OpenAPI spec fits on one page)
// ✅ Changes to its internals do not require changes in other services
// ✅ Business language is consistent internally (ubiquitous language)

// Signs of a poorly-bounded service (distributed monolith):
// ❌ Service A calls Service B synchronously for every request
// ❌ Two services share the same database/schema
// ❌ Deploying one service requires deploying 5 others simultaneously
// ❌ The "Order" entity is 50 fields serving 8 different use cases

// Starting heuristic: if a business capability can be described in one sentence
// and owned by one team, it is likely a good bounded context.
// Examples:
// - "Manages the lifecycle of customer orders from placement to payment" → Order + Payment context
// - "Tracks warehouse inventory and fulfils pick lists"  → Fulfilment context
// - "Manages customer profiles, preferences, and history" → CRM context