Domain-Driven Design
SimulationBank’s domain model follows DDD principles with clearly defined:- Entities: Objects with unique identity
- Value Objects: Immutable objects defined by their attributes
- Aggregates: Clusters of entities and value objects
- Domain Events: Significant occurrences in the domain
Core Entities
DiscreteEventSimulation
Aggregate Root - The central entity coordinating the entire simulation.- Advance simulation clock
- Process events in chronological order
- Allocate tellers to customers
- Maintain system state
- Clock never moves backward
- Events processed in order
- Queue size ≤ max_queue_capacity
- Number of tellers remains constant during simulation
Customer
Entity - Represents a bank customer with unique identity.WAITING- In queueBEING_SERVED- At teller windowCOMPLETED- Service finished
Teller
Entity - Represents a service window/resource.start_service(customer, current_time)- Begin servingend_service()- Complete service, return to IDLE
Value Objects
SimulationConfig
Immutable configuration for simulation parameters.Value objects are immutable. Changes require creating a new instance.
Priority
Enum representing customer priority levels.TransactionType
Enum for types of banking transactions.TellerStatus
Enum for teller operational states.SimulationStatus
Enum for simulation lifecycle states.Domain Events
SimulationEvent
Value Object representing significant occurrences.EventType
Enum of possible event types.Aggregates
Simulation Aggregate
Root:DiscreteEventSimulation
Members:
- Collection of
Tellerentities - Collection of
Customerentities (in queue) SimulationConfigvalue object- Collection of
SimulationEventvalue objects
Domain Services
CustomerGenerator
Port (interface) defined in domain layer.ConfigurableGenerator in infrastructure layer.
MetricsRepository
Port for persisting metrics.InMemoryMetricsRepository in infrastructure layer.
Ubiquitous Language
Key domain terms used consistently:| Term | Definition |
|---|---|
| Simulation | A discrete event model of bank operations |
| Clock | Simulated time (not real-time) |
| Event | A scheduled occurrence at a specific time |
| Arrival | Customer entering the bank |
| Queue | Waiting customers ordered by priority |
| Teller | Service window/resource |
| Service | Time spent at teller window |
| Priority | Customer service order (High/Medium/Low) |
| Utilization | Percentage of time teller is busy |
| Throughput | Customers served per time unit |
| Wait Time | Time from arrival to service start |
Invariants and Business Rules
Queue Invariants
- Customers ordered by priority (ascending)
- Within same priority, ordered by arrival time (FIFO)
- Queue size never exceeds
max_queue_capacity
Teller Invariants
- Teller can serve at most one customer at a time
current_customeris None if and only if status is IDLEsessions_servedis monotonically increasing
Simulation Invariants
- Clock is monotonically increasing
- Event queue ordered by time
- Simulation stops when clock ≥
max_simulation_time
Business Rules
- Priority Service: Higher priority customers (priority=1) are served before lower priority (priority=3)
- FIFO Within Priority: Among same priority, first arrival is served first
- Resource Allocation: Idle tellers immediately serve waiting customers
- Capacity Limits: Customers rejected if queue is at maximum capacity
Next Steps
Simulation Engine
See how these entities work together in the simulation loop
Customer Module
Learn about customer generation and lifecycle
Queue Module
Understand priority queue implementation
Teller Module
Explore teller operations and state management