How SOLID principles guide the system's structure, and which design patterns are applied to solve recurring architectural challenges.
Three of the five SOLID principles and their concrete application in Abokabot.
Each service in Abokabot is scoped to one bounded context. The Ticketing Service handles ticket lifecycle only; fare calculation is delegated to a dedicated FareEngine class. This means a regulatory change to fare rules requires modifying only FareEngine without touching TicketingService, reducing the blast radius of changes and simplifying unit testing.
The FareEngine uses a strategy pattern internally, making it open for extension but closed for modification. When a new passenger category (e.g., "military discount") is introduced, a new FareStrategy implementation is added without modifying existing strategy code. The engine selects the appropriate strategy at runtime based on user role, keeping the core stable.
High-level services depend on abstractions, not concretions. The TicketingService depends on a CardValidationPort interface, not directly on MengedApiClient. This decouples the business logic from the external payment system. During testing, a MockMengedAdapter satisfies the interface, enabling full integration tests without real Menged API calls. If Menged is replaced by another payment system, only the adapter changes.
Singleton and Observer patterns: the problem each solves and how they integrate into the architecture.
System-wide configuration (API keys, timeout thresholds, Menged endpoint URLs) was scattered across multiple service files, causing inconsistencies when values were updated and making environment-specific deployments error-prone.
A SystemConfig Singleton class is instantiated once at application startup, reading from environment variables. All services obtain configuration by calling SystemConfig.getInstance(). This guarantees a single source of truth, prevents conflicting config values, and enables centralized reload logic without restarting services.
Sits at the infrastructure layer, consumed by the API Gateway and all microservices. In a containerized deployment, each container instance has its own Singleton, which is correct behavior since config is per-process, not per-request.
Multiple system components needed to react when a boarding event occurred: the audit log needed to record it, the operator dashboard needed a real-time count update, and a fraud detection module needed to analyze the event. Tightly coupling TicketingService to all these consumers created a god-class anti-pattern.
The TicketingService emits a BoardingEvent to an internal event bus. The AuditLogger, OperatorDashboardNotifier, and FraudDetector are registered as observers. Each reacts independently when a boarding event is published. Adding a new observer (e.g., analytics service) requires no modification to TicketingService.
Implemented as a lightweight in-process event emitter. In the cloud deployment, this scales to a message broker (e.g., RabbitMQ) for cross-service observers, maintaining the same decoupled contract without architectural rework.
Structural representation of the Singleton and Observer implementations.