habibsql/TheMicroServices

This system is a .NET-based microservices architecture designed to manage retail operations, specifically focusing on inventory tracking and purchase processing. It comprises an Inventory Microservice that maintains store and item data via a CQRS pattern and MongoDB, and a Purchase Microservice that handles order creation and history retrieval. The services communicate asynchronously through RabbitMQ events and synchronously via gRPC, with resilience mechanisms like circuit breakers ensuring stability during inter-service calls.

This change introduces the complete Inventory Microservice, establishing a new domain for managing store and inventory data. It includes a gRPC API for querying total item counts, a REST API for creating stores and querying store lists, and a domain model built on a CQRS pattern with MongoDB persistence. The service also features an event-driven architecture using RabbitMQ to handle product purchase and sales events, automatically updating inventory balances in response to these external events.

Src/InventoryMicroservice · high confidence

This change introduces the complete Purchase Microservice, enabling users to create product purchases and query purchase history. The service exposes REST endpoints for submitting purchase orders (including line items) and retrieving paginated, sorted purchase records. It implements a CQRS architecture with command and query handlers, persists data to MongoDB, and integrates with RabbitMQ for event publishing. Additionally, the purchase command handler includes a circuit breaker policy for resilience when calling an external Inventory Service via gRPC.

Src/PurchaseMicroservice · high confidence

This change introduces the foundational project structure and dependency configurations for the Inventory, Purchase, and Sales microservices, along with shared Common libraries. It establishes .NET Core 3.1 for web APIs and test projects, and .NET Standard 2.1 for shared logic and domain layers. Key dependencies added include Grpc.AspNetCore (2.24.0) and Grpc.Core (2.33.1) for gRPC communication, MongoDB.Driver (2.11.0) for data persistence, RabbitMQ.Client (6.2.1) for messaging, and Polly (7.2.1) for resilience. Testing infrastructure is set up using xUnit (2.4.0), FluentAssertions (5.10.3), and Moq (4.14.7).

(dependencies) · high confidence

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

• CAI 42 → 41 (-0.4)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 53 → 53 (-0.0)
• Architecture 86 → 86 (+0.2)
• Maturity 56 → 56 (+0.0)
• Readiness 36 → 33 (-3.0)
• Security 38 → 38 (-0.3)
• Domain Modelling 45 → 54 (+8.3)
• Event-Driven 84 → 84 (+0.0)

• Bounded contexts not declared
• Coverage not measured — analyzer environment
• Inconsistent naming for bus interfaces and implementations: 'CommandBus' vs 'QueryBus'. While distinct, the prefix 'Common.Core' vs 'Common.Infrastructure' is consistent, but the term 'Bus' is used. However, 'ICommandBus' and 'IQueryBus' are consistent. The issue is the implementation classes 'CommandBus' and 'QueryBus' vs 'EventBus'.
• Inconsistent naming for constants classes: 'MessageQueues' (plural) vs 'MessageQueue' (singular).
• Inconsistent naming for domain models: 'ProductLineItem' vs 'SalesLineItem'. One uses 'Product' and the other 'Sales' for what appears to be a line item in a transaction.
• Inconsistent naming for email-related classes: 'EmailSettings' vs 'EmailParams'. One implies configuration, the other data transfer.
• Inconsistent naming for event/line item types: 'PurchasedLineItem' vs 'ProductSoldLineItem' vs 'PurchasedLineItem'. The prefix 'Product' is missing in some, and 'Sold' vs 'Purchased' is inconsistent across similar concepts.
• Inconsistent naming for product ID: 'ProductId' vs 'PurchaseId'. While they might be different, the context suggests 'ProductId' is used in DTOs and events, but 'PurchaseId' is used in other events.
• Inconsistent naming for search/query methods: 'SearchPurchases' vs 'FindSoldProductInfo'. One uses 'Search' and the other 'Find', and the parameters differ significantly.
• Inconsistent naming for unit-related properties: 'PurchaseUnitName' vs 'UnitName'. The prefix 'Purchase' is used in one place but not others.
• Inconsistent naming for user/owner properties: 'Name' vs 'Manager'. 'Name' is generic, 'Manager' is specific. If 'Manager' refers to a person, 'Owner' or 'Manager' should be consistent.
• Medium CVE: MongoDB.Driver 2.11.0
• Medium CVE: SharpCompress 0.23.0
• Medium CVE: SharpCompress 0.23.0
• No exposed public API
• Test runner surfaced no tests
• Typo in method name: 'Decerialize' should be 'Deserialize' to match standard C# naming conventions and the corresponding 'Serialize' method.
• early-stage repository — too few commits for a meaningful bus factor
• early-stage repository — too little history to judge knowledge freshness
• redundant comment (Src/PurchaseMicroservice/PurchaseCommandHandler/PurchaseCommandHandler.cs)

• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (10 lines × 4) (Src/InventoryMicroservice/Inventory.Api.Grpc/Program.cs)
• Duplicated block (5 lines × 2) (Src/PurchaseMicroservice/PurchaseWebApi/Startup.cs)
• End-of-life runtime: .NET netcoreapp3.1
• High IaC: WD-DOCKER-0013 (Src/InventoryMicroservice/Inventory.Api.Grpc/Dockerfile)
• High IaC: WD-DOCKER-0013 (Src/InventoryMicroservice/Inventory.Api.Grpc/Dockerfile)
• High IaC: WD-DOCKER-0013 (Src/SalesMicroservice/SalesWebApi/Dockerfile)
• High IaC: WD-DOCKER-0013 (Src/SalesMicroservice/SalesWebApi/Dockerfile)
• Inconsistent naming for line item entities: 'ProductSoldLineItem', 'PurchasedLineItem', and 'ProductLineItem' are used in different contexts (Events vs Domain Model). While they may represent different concepts, the lack of a consistent prefix or suffix pattern (e.g., always 'LineItem' or always 'Item') across the domain and event models creates confusion.
• Inconsistent pluralization in Constants classes: 'EmailAddressess' (typo + plural) vs 'MessageQueues' (plural) vs 'MessageQueue' (singular). While 'MessageQueue' and 'MessageQueues' might refer to different specific constants, the typo 'EmailAddressess' is inconsistent with standard spelling, and the mix of singular/plural in similar constant containers suggests a lack of convention.
• Medium CVE: SharpCompress 0.23.0
• Medium IaC: WD-DOCKER-0003 (Src/InventoryMicroservice/Inventory.Api.Grpc/Dockerfile)
• Medium IaC: WD-DOCKER-0003 (Src/InventoryMicroservice/Inventory.Api.Grpc/Dockerfile)
• Medium IaC: WD-DOCKER-0003 (Src/SalesMicroservice/SalesWebApi/Dockerfile)
• Medium IaC: WD-DOCKER-0003 (Src/SalesMicroservice/SalesWebApi/Dockerfile)
• No assertions: ShouldReceiveMessageWhenValidQueueProvided (Src/CommonAll/Common.Infrastructure.Tests/RabbitMqServiceBusTest.cs)
• Test project verifies nothing: Common.Core.Tests (Src/CommonAll/Common.Core.Tests/UnitTest1.cs)
• Test project verifies nothing: Common.Infrastructure.Tests (Src/CommonAll/Common.Infrastructure.Tests/RabbitMqServiceBusTest.cs)
• Typo in interface name: 'IPurchaseRepostiory' vs 'IPurchaseRepository'. The interface name contains a typo ('Repostiory' instead of 'Repository'), while the implementing class uses the correct spelling. This creates a naming inconsistency between the contract and the implementation.
• …and 1 more

• Unchanged — 9 HTTP endpoints

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

habibsql/TheMicroServices 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.