4. Solution Strategy
April 11, 2026 · View on GitHub
4.1 Technology Decisions
| Decision | Rationale |
|---|---|
| Microservices architecture | Demonstrates decomposition, independent deployability, per-service data ownership, and eventual consistency. See ADR-0001. |
| .NET / ASP.NET Core | Author's expertise; single-stack keeps the solution accessible to .NET developers. See ADR-0002. |
| RabbitMQ | Push-based event notification with queue semantics; simpler than Kafka for the educational scope. See ADR-0003. |
| SQL Server | Single database platform avoids polyglot-persistence complexity. See ADR-0007. |
| Docker / Kubernetes | Containerisation is the standard deployment model. Kubernetes manifests enable orchestration demos. See ADR-0010. |
4.2 Architectural Patterns & Approaches
| Pattern | Where Applied | Purpose |
|---|---|---|
| Event-Driven Architecture | All services | Services communicate asynchronously through domain events published to RabbitMQ. This decouples services and enables eventual consistency. |
| Domain-Driven Design (DDD) | WorkshopManagementAPI | The core bounded context uses Aggregates (WorkshopPlanning), value objects, and domain events to model complex business rules. |
| Event Sourcing | WorkshopManagementAPI | The WorkshopPlanning aggregate persists its state as a sequence of domain events in a dedicated event store, rather than as current-state snapshots. See ADR-0004. |
| CQRS | WorkshopManagementAPI | Commands are transformed into events that modify the aggregate; a separate read-model is built by the WorkshopManagementEventHandler for query purposes. |
| CRUD | CustomerManagementAPI, VehicleManagementAPI | Supporting bounded contexts with simple lifecycle; Entity Framework Core with code-first migrations. |
| Messaging Abstraction | Infrastructure.Messaging library | IMessagePublisher and IMessageHandler interfaces decouple all services from the concrete broker implementation. See ADR-0009. |
4.3 Key Design Decisions
-
Different design approaches per bounded context — Workshop Management (core domain) uses DDD + event sourcing; Customer and Vehicle Management (supporting domains) use simple CRUD. This demonstrates that different services warrant different levels of design complexity.
-
Dedicated Time Service — Rather than using internal timers or cron jobs, a dedicated service publishes
DayHasPassedevents. This makes time-dependent behaviour fully deterministic and testable. See ADR-0005. -
No API Gateway — The WebApp calls backend APIs directly using Refit typed HTTP clients. This keeps the solution focused on core microservices patterns. See ADR-0006.
-
Centralized logging with Seq — All services use Serilog for structured logging and send log events to a central Seq server. This provides a single pane of glass for observability. See ADR-0008.
-
Read-model in Workshop Management — The WorkshopManagementEventHandler builds a read-model with cached Customer and Vehicle data. This ensures Workshop Management can operate autonomously even when other services are offline.