mohamed-abdo/vehicle-tracking-microservices

This is a vehicle tracking microservices system designed to ingest, store, and query vehicle status and telemetry data. It comprises distinct services for handling pings, tracking, and customer data, orchestrated via Docker Compose and communicating through RabbitMQ and Redis. The architecture leverages event sourcing with SQL persistence and implements a Mediator pattern for internal request handling and message routing.

The repository now includes a complete Docker Compose setup to orchestrate the vehicle tracking system's microservices. This adds \docker-compose.yml\ and related configuration files that define the \ping\, \tracking\, \vehicle\, and \customer\ services, along with their dependencies on Redis, RabbitMQ, and SQL Server. The configuration also introduces a CI build pipeline and a test environment, enabling local development and automated testing of the distributed system.

vehicle-tracking-poc · high confidence

Introduced a new Redis-based caching layer for the vehicle-tracking proof-of-concept. The change adds a \CacheManager\ implementation and \ICacheProvider\ interface that support string, binary, hash, and set operations, enabling the tracking service to store and retrieve data via Redis.

vehicle-tracking-poc/Components/RedisCacheAdapter · high confidence

A new CustomerController has been added to expose API endpoints for retrieving and creating customer and vehicle data. The controller implements GET and POST methods that interact with a Mediator pattern to handle customer requests and track vehicle information, supporting the vehicle tracking proof-of-concept.

vehicle-tracking-poc/Customer/Controllers · medium confidence

A new static class named 'Fields' has been added to the BuildingAspects.Formatters namespace. This class provides static helper methods that format various vehicle tracking data points—such as vehicle, customer, timestamp, status, message, brand, and model—by prefixing them with a specific string (e.g., 'vehicle:'). This change introduces new formatting capabilities for these specific data fields.

vehicle-tracking-poc/Components/BuildingAspects/Formatters · medium confidence

New data models have been introduced to support vehicle tracking functionality. The system now includes a VehicleRequest model containing fields for chassis number, model, color, production year, country, and customer ID, along with a corresponding VehicleResponse model that maps domain data to a structured response including correlation ID, vehicle details, and features. Additionally, an Identifiers class has been added to define domain model constants.

vehicle-tracking-poc/Vehicle/Models · medium confidence

Introduced new data models for the vehicle tracking system: a VehicleStatus enumeration defining active, inactive, warning, and critical states, a PingRequest class for status updates, and an Identifiers class containing domain and service constants.

vehicle-tracking-poc/Ping/Models · high confidence

A new VehicleController is introduced to handle vehicle tracking requests. It exposes a GET endpoint to retrieve vehicle data by customer ID and a POST endpoint to publish vehicle information via a mediator pattern, supporting the core vehicle tracking functionality.

vehicle-tracking-poc/Vehicle/Controllers · high confidence

New Mediator pattern implementations have been introduced to handle customer and vehicle requests. The \CustomerRequest\ and \CustomerRequestHandler\ process customer queries, enriching the response by fetching and linking associated vehicle data. Additionally, \CustomerPublisher\ and \CustomerPublisherHandler\ manage event sourcing notifications for customer updates, ensuring that correlation IDs are correctly propagated through headers for tracing.

vehicle-tracking-poc/Customer/Controllers/Mediator · medium confidence

New Mediator pattern implementations have been introduced for vehicle tracking operations. The system now includes a VehiclePublisher and its corresponding handler to process vehicle-related notifications, as well as a VehicleRequest and its handler to process vehicle-related requests. Both handlers are designed to inject a correlation ID into HTTP request headers, enabling end-to-end request tracing across the service.

vehicle-tracking-poc/Vehicle/Controllers/Mediator · high confidence

A new PingController has been introduced to handle vehicle tracking pings. The POST endpoint accepts a vehicle ID and a status payload, mapping the incoming vehicle status to the appropriate internal status model. The controller publishes a PingPublisher notification via MediatR, which is handled by PingPublisherHandler to forward the request with a generated correlation ID and operational unit context to the message publisher.

vehicle-tracking-poc/Ping/Controllers · high confidence

Introduced a new Postman collection named 'vehicle-tracking-Microservices' containing test scripts for the Customer and Vehicle services. The collection includes API requests to add and retrieve customers and vehicles, with test assertions for status codes, response times, and correlation IDs. An accompanying environment file 'vehicle-tracking-local' was added, defining local service endpoints (pingSrv, trackingSrv, vehicleSrv, customerSrv) and initial values for customerId, chassisNumber, and correlationId.

postman-API-unit-test · high confidence

The BackgroundMiddleware component now includes new classes to interact with RabbitMQ: BackgroundService provides a base for hosted services; RabbitMQPublisher handles sending messages to an exchange; RabbitMQRequestClient manages request/response communication with a reply queue; and RabbitMQRequestWorker and RabbitMQSubscriberWorker handle consuming messages from queues and exchanges respectively. These changes enable the application to publish and subscribe to RabbitMQ-based messaging.

vehicle-tracking-poc/Components/BackgroundMiddleware · medium confidence

Introduced new helper classes in the Behaviors namespace to support application functionality. Defaults.cs provides standardized JSON serialization settings and cache timeout configurations. Function.cs implements an async retry mechanism using Polly for transient failure handling. Resilience.cs defines reusable Polly policies for circuit breaking, fallbacks, and timeouts to improve system stability. Utilities.cs adds object serialization (JSON and binary) and reflection-based comparison helpers. These changes provide the underlying infrastructure for reliable service interactions and data handling.

vehicle-tracking-poc/Components/BuildingAspects/Behaviors · high confidence

New domain model classes have been introduced to support customer, vehicle, and tracking data structures. This includes the Customer and Vehicle models with their respective filter models, a Tracking model containing vehicle telemetry data, a Ping model for status updates, and a StatusModel enum defining possible states such as active, warning, or critical. These models provide the underlying data structures required for the vehicle tracking system.

vehicle-tracking-poc/DomainModels/Business · high confidence

New adapter classes, PingEventSourcingLedgerAdapter and TrackingEventSourcingLedgerAdapter, have been added to the Adapters directory. These implement the IQueryEventSourcingLedger interface to handle querying for PingModel and TrackingModel respectively, bridging the domain models with the underlying EventSourcingLedger and DbModel representations.

vehicle-tracking-poc/EventSourcing/EventSourceingSqlDb/Adapters · medium confidence

Introduced the core data access layer for vehicle tracking, including the Vehicle entity, a VehicleDbContext for SQL storage, and a VehicleManager class that implements command and query interfaces for adding and retrieving vehicle records.

vehicle-tracking-poc/VehicleSQLDB · high confidence

A new tracking controller and its associated Mediator request/handler classes have been added to the vehicle-tracking-poc service. The controller exposes a GET endpoint that accepts time range and pagination parameters, forwarding the request via MediatR to a handler that enriches the request with a generated correlation ID and forwards it to a message query. The response is transformed into a JSON result for the client.

vehicle-tracking-poc/Tracking/Controllers · medium confidence

The repository was initialized with standard configuration files (.gitattributes, .gitignore) and a comprehensive README that defines the vehicle tracking microservices architecture. The documentation outlines the domain model for vehicle status and customer data, specifies API contracts via Swagger, and details features for vehicle ping and tracking dashboards.

(repo-wide) · high confidence

The Vehicle service is introduced as a new microservice, bootstrapped via a Dockerfile and ASP.NET Core startup configuration. It registers a SQL database context with retry-on-failure resilience, sets up RabbitMQ-based message handling for vehicle updates and queries, and configures logging and caching infrastructure.

vehicle-tracking-poc/Vehicle · medium confidence

A new EventSourcingMiddleware service is added, built on ASP.NET Core and Kestrel, to handle event sourcing operations. The service configures an SQL Server database context with retry logic, registers a RabbitMQ subscriber background worker to process incoming messages, and sets up structured logging via Serilog. The middleware exposes a basic HTTP endpoint for health checks and status reporting, and includes a Dockerfile for containerization.

vehicle-tracking-poc/EventSourcing/EventSourcingMiddleware · high confidence

Added new interfaces for message handling (IMessageCommand, IMessageRequest) and operational unit context (IOperationalUnit) along with the OperationalUnit implementation, establishing the foundation for point-to-point service communication and correlation tracking within the vehicle tracking system.

vehicle-tracking-poc/Components/BuildingAspects/Services · medium confidence

The update adds new \Customer\ and \Tracking\ microservices, each with their own Dockerfiles, startup configurations, and background workers that subscribe to RabbitMQ message queues. The \Customer\ service persists customer data to a SQL database and caches it in Redis, while the \Tracking\ service manages vehicle tracking data, also using SQL and Redis for caching. Both services are configured to handle RPC-style requests via RabbitMQ, enabling asynchronous communication between the customer and tracking domains.

vehicle-tracking-poc/Tracking · high confidence

Added new Mappers and Validators classes in the EventSourceingSQLDB Functors namespace to handle the transformation between database models and domain messages. The Mappers class provides static methods to convert between DbModel and message structures (header, body, footer), while the Validators class includes a placeholder for model validation logic.

vehicle-tracking-poc/EventSourcing/EventSourceingSqlDb/Functors · medium confidence

Added new domain model files that define the system's configuration and filtering interfaces. IFilter.cs introduces an IFilter interface for query parameters like time ranges and pagination. Identifiers.cs provides constants for infrastructure settings, including cache servers, message middleware details, and service names. MiddlewareConfiguration.cs and ServiceConfiguration.cs establish the base class and implementation for loading configuration from key-value pairs, enabling the application to dynamically read settings for caching, messaging, and database connections.

vehicle-tracking-poc/DomainModels/System · medium confidence

The Ping service is introduced as a new .NET Core application designed to receive and process vehicle tracking data. The implementation includes a Kestrel-based web host with startup configuration for dependency injection, including MediatR for command/query handling, Redis caching, and RabbitMQ message publishing. The service is containerized via a new Dockerfile and configured with environment-specific settings (appsettings.json) and Swagger documentation for API discovery.

vehicle-tracking-poc/Ping · high confidence

A new event-sourcing database model has been added to the vehicle-tracking-poc project, enabling the persistence of vehicle tracking events in SQL. The change introduces a \DbModel\ class that maps event data, headers, and footers to a relational schema, along with a \DbModelFactory\ to convert between domain models and database entities. An \EventSourcing\ entity and its corresponding \DbContext\ are also added, allowing the system to store and retrieve event-sourced data for vehicle tracking scenarios.

vehicle-tracking-poc/EventSourcing/EventSourceingSqlDb/DbModels · medium confidence

A new event sourcing repository implementation has been added to the vehicle-tracking-poc project, enabling persistence of events to a SQL database. The change introduces a base class (BaseEventSourcingLedger) and a concrete implementation (EventSourcingLedger) that supports adding events and querying them with support for service filtering, time ranges, and pagination. This provides the underlying storage mechanism for the vehicle tracking feature's event sourcing architecture.

vehicle-tracking-poc/EventSourcing/EventSourceingSqlDb/Repository · high confidence

Adds new domain model types to the vehicle-tracking-poc system, including a generic DomainModel class and IDomainModel interface for message headers, bodies, and footers. Also introduces IDescribe for string-based model descriptions, IOptional for optional value handling, and an Identifiers class containing constants for message routing, correlation IDs, and content types.

vehicle-tracking-poc/DomainModels/Types · medium confidence

Added new C\# models to the Customer service to support event sourcing and API endpoints. The changes include CustomerRequest and CustomerResponse classes that map customer details (name, mobile, email, birth date, country) and a CorrelationId. A corresponding VehicleResponse model was also added to expose vehicle attributes (chassis number, model, color, production year, features). These models enable the service to handle customer registration requests and return enriched customer and vehicle data in responses.

vehicle-tracking-poc/Customer/Models · medium confidence

The system now supports structured error handling via a new \CustomException\ class that maps integer error codes to user-friendly messages and response hints. Additionally, the codebase introduces \MessageHeader\ and \MessageFooter\ models (along with their interfaces) to standardize message metadata, including execution and correlation IDs, timestamps, and environment details. These changes provide a more robust way to handle errors and track message context across the application.

vehicle-tracking-poc/DomainModels/Types/Messages · high confidence

The web component layer now enforces a uniform response structure across all endpoints. New interceptors and middleware (CustomAuthonticator, CustomAuthorizer, CustomHeader, CustomResponseResult, CustomeExceptoinHandler, CustomResponse) automatically inject metadata headers (correlation ID, route, environment, hints) and serialize the response body into a standardized JSON format containing header, body, and footer sections. This ensures every API response includes consistent tracing and error information, while unhandled exceptions are caught and returned as structured error objects rather than raw stack traces.

vehicle-tracking-poc/Components/WebComponents · high confidence

A new static helper class is introduced to parse host names and port numbers from connection strings. This utility extracts the host and port components, validating that the port is a valid integer, which supports vehicle tracking integration tests.

vehicle-tracking-poc/Components/BuildingAspects/Utilities · medium confidence

Add integration tests for vehicle tracking service; Added integration tests for the Ping service; Added unit tests for the Ping event sourcing ledger; Added unit tests for the PingController.

The vehicle-tracking-poc solution is initialized with 19 new .csproj files defining the project structure and dependencies. This includes the core domain models, SQL database contexts for Customer, Vehicle, and Tracking, and specific components like BackgroundMiddleware, BuildingAspects, RedisCacheAdapter, and WebComponents. The dependencies include Microsoft .NET Core 2.0 framework, Entity Framework Core 2.0.2, Serilog for logging, MediatR for messaging, and various Microsoft.Extensions libraries for logging, configuration, and hosting.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 35 → 35 (+0.4)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 48 → 45 (-2.3)
• Architecture 88 → 87 (-1.0)
• Maturity 52 → 52 (+0.0)
• Readiness 32 → 32 (+0.0)
• Security 24 → 23 (-1.6)
• Event-Driven 100 (new)

• Bounded contexts not declared
• Build status unknown
• Duplicated block (13 lines × 3) (vehicle-tracking-poc/Tracking/Startup.cs)
• Duplicated block (19 lines × 2) (vehicle-tracking-poc/Components/BackgroundMiddleware/RabbitMQPublisher.cs)
• Duplicated block (21 lines × 2) (vehicle-tracking-poc/Tracking/Program.cs)
• Duplicated block (23 lines × 3) (vehicle-tracking-poc/Vehicle/Startup.cs)
• Duplicated block (25 lines × 4) (vehicle-tracking-poc/Tracking/Startup.cs)
• LLM evaluation failed
• Medium IaC: CKV_DOCKER_3 (vehicle-tracking-poc/Customer/Dockerfile)
• Medium IaC: CKV_DOCKER_3 (vehicle-tracking-poc/EventSourcing/EventSourcingMiddleware/Dockerfile)
• Medium IaC: CKV_DOCKER_3 (vehicle-tracking-poc/Ping/Dockerfile)
• Medium IaC: CKV_DOCKER_3 (vehicle-tracking-poc/Tracking/Dockerfile)
• Medium IaC: CKV_DOCKER_3 (vehicle-tracking-poc/Vehicle/Dockerfile)
• No exposed public API
• Test runner surfaced no tests
• XML-doc coverage: VehicleTests (vehicle-tracking-poc/VehicleTests/VehicleTests.csproj)
• redundant comment (vehicle-tracking-poc/Components/BackgroundMiddleware/RabbitMQRequestClient.cs)
• redundant comment (vehicle-tracking-poc/Customer/Controllers/Mediator/CustomerPublisherHandler.cs)
• single-maintainer — knowledge-concentration (bus factor) risk

• Documentation: hard to navigate (README.md)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (12 lines × 2) (vehicle-tracking-poc/Components/BackgroundMiddleware/RabbitMQPublisher.cs)
• Duplicated block (15 lines × 2) (vehicle-tracking-poc/Components/BackgroundMiddleware/RabbitMQRequestWorker.cs)
• Duplicated block (16 lines × 2) (vehicle-tracking-poc/Components/BackgroundMiddleware/RabbitMQRequestWorker.cs)
• Duplicated block (18 lines × 2) (vehicle-tracking-poc/Components/BackgroundMiddleware/RabbitMQRequestWorker.cs)
• Duplicated block (18–22 lines × 3) (vehicle-tracking-poc/Customer/Startup.cs)
• Duplicated block (19–23 lines × 2) (vehicle-tracking-poc/Customer/Startup.cs)
• Duplicated block (20–21 lines × 3) (vehicle-tracking-poc/Components/WebComponents/Interceptors/CustomAuthorizer.cs)
• Duplicated block (21 lines × 5) (vehicle-tracking-poc/Customer/Program.cs)
• Duplicated block (26 lines × 4) (vehicle-tracking-poc/Customer/Startup.cs)
• Duplicated block (30 lines × 4) (vehicle-tracking-poc/Customer/Startup.cs)
• Duplicated block (31 lines × 4) (vehicle-tracking-poc/Customer/Program.cs)
• Duplicated block (31–32 lines × 2) (vehicle-tracking-poc/Components/BackgroundMiddleware/RabbitMQPublisher.cs)
• Duplicated block (32–38 lines × 3) (vehicle-tracking-poc/Customer/Startup.cs)
• Duplicated block (41–46 lines × 2) (vehicle-tracking-poc/Customer/Startup.cs)
• Duplicated block (7 lines × 3) (vehicle-tracking-poc/Customer/Models/VehicleResponse.cs)
• Duplicated block (8 lines × 2) (vehicle-tracking-poc/Customer/Models/CustomerResponse.cs)
• Duplicated block (9 lines × 2) (vehicle-tracking-poc/Customer/Models/VehicleResponse.cs)
• …and 38 more

• Unchanged — 8 HTTP endpoints

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

mohamed-abdo/vehicle-tracking-microservices was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.