Context Map

The Context Map visualizes the different bounded contexts in the Bartendie system and how they relate to each other. It helps in understanding the system boundaries and integration points.

What is a Context Map?

A Context Map is a strategic design tool from Domain-Driven Design that shows:

The different bounded contexts in a system
Their relationships and integration patterns
The teams or actors that interact with each context
External systems and their integration points

Bounded Contexts in Bartendie

The diagram below shows the key bounded contexts in the Bartendie system:

graph TD
    %% Bounded Contexts
    subgraph "Bartendie Domain"
        E[Event Planning Context]
        M[Menu Management Context]
        I[Inventory Management Context]
        P[Cocktail Preparation Context]
        G[Guest Experience Context]
        B[Bar Setup Context]
        R[Recipe Management Context]
        T[Tagging System Context]
        F[Flavor Profile Context]
        C[Scaling & Batch Context]
        S[Shopping Context]
        Q[Equipment Management Context]
        V[Venue Management Context]
        U[User Management Context]
        N[Notification Context]
        A[Audit & History Context]
    end
    
    %% Relationships between contexts with more detailed labels
    E -->|schedules and defines theme for| M
    E -->|creates and manages| G
    E -->|takes place at| V
    M -->|requires ingredients from| I
    M -->|selects recipes from| R
    M -->|influences| B
    M -->|drives| P
    M -->|analyzed for flavor balance in| F
    I -->|generates needs for| S
    I -->|supports| P
    I -->|tracks| Q
    I -->|is stored in| V
    P -->|uses| Q
    P -->|follows| R
    P -->|delivers| G
    P -->|creates| C
    B -->|enhances| G
    B -->|includes| Q
    B -->|is set up in| V
    G -->|provides feedback to| R
    G -->|influences future| E
    R -->|categorized by| T
    R -->|analyzed in| F
    R -->|scaled by| C
    T -->|applied to multiple contexts| E
    T -->|organizes| R
    T -->|categorizes| I
    F -->|influences| R
    F -->|enhances| M
    F -->|matches with| G
    C -->|uses data from| G
    C -->|applies to| R
    C -->|informs| S
    S -->|updates| I
    Q -->|linked to| R
    U -->|authenticates| E
    U -->|manages permissions for| I
    U -->|controls access to| V
    N -->|sends alerts about| I
    N -->|notifies about| E
    N -->|communicates| G
    A -->|tracks changes to| E
    A -->|logs operations in| I
    A -->|records| R

    %% External Systems
    X1[(Supplier System)]
    X2[(Email/Messaging)]
    X3[(Product Database)]
    X4[(Barcode Scanner)]
    
    %% External System Relationships with Integration Patterns
    S -->|orders from via REST API| X1
    G -->|communicates through SMTP/Push| X2
    I -->|looks up products via ACL| X3
    I -->|scans products with SDK| X4

    %% Anti-Corruption Layers
    subgraph "Anti-Corruption Layers"
        ACL1[Product Data ACL]
        ACL2[Supplier Integration ACL]
        ACL3[Messaging ACL]
    end

    ACL1 -->|translates| X3
    ACL2 -->|adapts| X1
    ACL3 -->|formats| X2
    I -.->|uses| ACL1
    S -.->|uses| ACL2
    N -.->|uses| ACL3
    
    %% Actor Relationships
    AC1((Host))
    AC2((Bartender))
    AC3((Guests))
    
    AC1 -->|plans| E
    AC1 -->|creates| M
    AC1 -->|manages| I
    AC1 -->|collects feedback from| G
    AC2 -->|executes| P
    AC2 -->|sets up| B
    AC2 -->|maintains| I
    AC2 -->|creates and refines| R
    AC3 -->|provides| G
    AC3 -->|influences| M
    
    %% Context Types - Core, Supporting, Generic
    classDef core fill:#ff9900,stroke:#333,stroke-width:2px;
    classDef supporting fill:#66ccff,stroke:#333,stroke-width:2px;
    classDef generic fill:#cccccc,stroke:#333,stroke-width:2px;
    
    %% External Systems & Actors
    classDef external fill:#ff4081,stroke:#333,stroke-width:2px;
    classDef actor fill:#4CAF50,stroke:#333,stroke-width:2px,color:#fff,shape:circle;
    classDef acl fill:#ffeb3b,stroke:#333,stroke-width:2px;
    
    %% Assigning classes
    class E,M,P,R,G core;
    class I,B,F,C,S,Q,V,N,A supporting;
    class T,U generic;
    class X1,X2,X3,X4 external;
    class AC1,AC2,AC3 actor;
    class ACL1,ACL2,ACL3 acl;
    
    %% Legend/Notes
    subgraph "Legend"
        L1[Core Domain]:::core
        L2[Supporting Domain]:::supporting
        L3[Generic Domain]:::generic
        L4[(External System)]:::external
        L5((Actor)):::actor
        L6[Context Relationship]
        L7[Anti-Corruption Layer]:::acl
    end

Core Domains

These are the most important domains that provide the main value of the system:

Event Planning Context: Manages events, themes, guests, and planning
Menu Management Context: Handles menu creation and drink selection for events
Cocktail Preparation Context: Covers the preparation and serving of drinks
Recipe Management Context: Manages cocktail recipes and their properties
Guest Experience Context: Focuses on guest preferences and feedback

Supporting Domains

These domains support the core domains:

Inventory Management Context: Tracks products, ingredients, and stock levels
Bar Setup Context: Manages the physical setup and arrangement for events
Flavor Profile Context: Analyzes and categorizes flavor characteristics
Scaling & Batch Context: Handles recipe scaling and batch preparation
Shopping Context: Manages shopping lists and procurement
Equipment Management Context: Tracks bar tools, equipment, and glassware
Venue Management Context: Manages physical locations for events, including their storage areas and bar setups
Notification Context: Handles alerts, reminders, and communications to users
Audit & History Context: Tracks changes, operations, and maintains system history

Generic Domains

These are common domains that could potentially be outsourced or use off-the-shelf solutions:

Tagging System Context: Provides categorization and organization through tags
User Management Context: Handles authentication, authorization, and user profiles

External Systems

The Bartendie system integrates with:

Supplier System: For ordering supplies and ingredients
Email/Messaging: For guest communications
Product Database: For product information lookup
Barcode Scanner: For scanning product barcodes

Key Actors

The system interacts with:

Host: Plans events, creates menus, and manages inventory
Bartender: Executes cocktail preparation, sets up the bar, and creates recipes
Guests: Provide preferences and feedback, influencing future menus and events

Context Relationships

The arrows in the diagram show how contexts relate to each other:

Customer/Supplier: Where one context provides services to another
Partnership: Where contexts collaborate to provide a feature
Shared Kernel: Where contexts share common models
Conformist: Where one context adapts to another’s model

Understanding these relationships helps in designing the integration points between different parts of the system and maintaining appropriate boundaries.

Integration Patterns

The system uses several integration patterns to maintain clean boundaries:

Anti-Corruption Layers (ACL)

Product Data ACL: Translates external product database formats into internal domain models
Supplier Integration ACL: Adapts supplier system APIs to internal shopping context needs
Messaging ACL: Formats and routes notifications through various communication channels

Integration Technologies

REST APIs: For synchronous communication with external systems
Event-Driven Architecture: For asynchronous communication between contexts
Message Queues: For reliable notification delivery
Database Integration: For shared data access patterns

Shared Kernels

Some contexts share common models:

Tagging System: Shared across Recipe, Inventory, and Event contexts
Flavor Profile: Shared between Recipe and Menu contexts
User Identity: Shared across all contexts requiring authentication

Team Ownership

Core Team: Event Planning, Menu Management, Recipe Management
Platform Team: User Management, Notification, Audit & History
Integration Team: External system ACLs and API management
Domain Teams: Inventory, Bar Setup, Venue Management (specialized domain knowledge)