Online Store — System Landscape

Identified Command records the request id before running the wrapped command, then catches any inner failure and returns false. The OrderStarted event that clears the basket is already saved in the same transaction, which still commits. A retry with the same id counts as a duplicate, so Create Order returns true and no order exists. This wrapper sits in front of 8 command handlers.

Impact: A buyer's basket can be cleared with no order created, and a retry hides the failure by reporting success, while every other order command inherits the same silent-catch idempotency behavior.

Recommendation (medium effort): In Identified Command's catch block, log the swallowed exception and return a result that distinguishes failure from a genuine duplicate, so a failed inner command cannot masquerade as a successful retry.

UpdateItem and CreateItem await CatalogAI.GetEmbeddingAsync before saving, with no try/catch, and CatalogAI calls the embedding generator directly. When the configured provider (Ollama or OpenAI, chosen at startup by the OllamaEnabled flag) is unreachable, the exception escapes the endpoint before anything is saved. In UpdateItem that happens before the price-changed event reaches the outbox, so a price update fails outright.

Impact: A price change (and any other catalog write) fails whenever the configured embedding provider is down, even though pricing has nothing to do with search.

Recommendation (small effort): Catch embedding failures in UpdateItem and CreateItem, log them and save without a vector, so an unreachable model cannot fail the write and its price-changed event.

CatalogIntegrationEventService saves each event to the outbox in the same transaction as the catalog change, then publishes it; if the publish throws, PublishThroughEventBusAsync only calls MarkEventAsFailedAsync. Nothing in the catalog service reads failed or pending outbox rows back to resend them, so Ordering can wait on a stock answer, or miss a price change, that never arrives.

Impact: A RabbitMQ publish failure leaves whichever service is waiting on that OrderStockConfirmed or price-change event stalled indefinitely, since nothing in this repo retries a failed or pending outbox row.

Recommendation (medium effort): Add a background sweep that reads failed and in-progress IntegrationEventLog rows and republishes them, so MarkEventAsFailedAsync is not a dead end.

OrderQueries is not a separate read model. All three of its queries run LINQ against the write side's EF Core OrderingContext and map its entities to DTOs by hand. Both order totals use Units × UnitPrice, the same formula as Order.GetTotal(), and neither subtracts the stored Discount. OrdersApi uses it for every order lookup, so a change to the Order aggregate's EF mapping changes what the API returns.

Impact: Any EF Core mapping change to the Order aggregate changes the shape or values the API returns, and the total shown to callers never reflects the per-item Discount stored on the order, since neither query subtracts it.

Recommendation (medium effort): Have OrderQueries subtract each item's Discount when computing Total, and treat the write model's mapping as a contract OrderQueries depends on — review it whenever the Order aggregate's schema changes.

Every RabbitMQ event handler in Ordering API sends its status command straight to MediatR and skips the IdentifiedCommand wrapper that HTTP requests get. SetPaidIdentifiedOrderStatusCommandHandler exists to ignore duplicates, but nothing sends it. The same is true for SetStockConfirmed, SetStockRejected and SetAwaitingValidation. A redelivered payment, stock or grace-period message runs a status change that was already applied.

Impact: A redelivered event from the payment, catalog or grace-period worker silently repeats an order status transition, with no idempotency check to stop it.

Recommendation (medium effort): Route each integration-event handler's status command through its existing Identified*OrderStatusCommandHandler (keyed by the event id) instead of calling mediator.Send on the bare command, the way OrdersApi already does for HTTP.

The awaiting-validation handler looks up each ordered product with CatalogItems.Find and skips any id that comes back null; it rejects only when a found item lacks stock. So an order made entirely of unknown product ids gets OrderStockConfirmedIntegrationEvent. Nothing is reserved either: the paid handler later calls CatalogItem.RemoveStock, which throws CatalogDomainException once stock is zero.

Impact: An order for a nonexistent or already-removed product clears validation as confirmed, and the failure only surfaces later as an unhandled exception when the paid handler tries to remove stock, instead of as a rejection at the point the catalog actually knows the product id is unrecognised.

Recommendation (small effort): In the awaiting-validation handler, treat a null CatalogItems.Find result as a rejected line instead of skipping it, so an order of unrecognised products is rejected before payment.

Order Status Notification Service is a singleton (Extensions.cs:26) that keeps subscriptions in an in-memory dictionary keyed by buyer id. All six RabbitMQ order-status handlers, such as OrderStatusChangedToPaidIntegrationEventHandler, call NotifyOrderStatusChangedAsync on it, and it wakes only the circuits subscribed in that same process. The event handlers have no other way to reach a buyer's open circuits.

Impact: With more than one WebApp replica behind a load balancer, a shopper whose browser circuit is on a different instance than the one that processed the RabbitMQ event never gets the live status refresh — their Orders page only updates on a manual reload.

Recommendation (medium effort): Replace the in-process subscription dictionary with a mechanism that fans out across replicas — a SignalR backplane, Redis pub/sub, or routing the notification through the message bus so every instance can push to its own local circuits.

BasketState.CheckoutAsync awaits OrderingService.CreateOrder and then unconditionally deletes the basket. CreateOrder returns the raw HttpClient.SendAsync result and never checks the status code, so a 400 or 500 from the Ordering API looks like success. Checkout.razor then navigates straight to the orders page with no failure branch. All 3 of Basket State's dependents go through it, so every checkout takes this path.

Impact: A shopper who submits an order the Ordering API rejects sees their cart emptied and lands on an order history page where the order they just placed does not appear, with no error and no way to recover the cart contents.

Recommendation (small effort): Have OrderingService.CreateOrder check the response status and throw or return a result on failure, and have BasketState.CheckoutAsync only clear the basket after a confirmed success; Checkout.razor should show an error and keep the cart when checkout fails.

Cart Menu loads the basket through Basket State, which looks up every basket line with catalogItems[item.ProductId] and throws when a product is missing from the catalog. Cart Menu's startup handler catches only an unauthorized error, so that lookup failure is never caught. Basket State caches the failing call, so the bag badge stays broken on every page until the basket itself changes.

Impact: One retired product leaves the bag badge failing on every page the shopper visits, not just the one where the stale item was added, until they change the basket.

Recommendation (medium effort): Have Basket State's basket load skip or flag a line whose product is no longer in the catalog instead of indexing straight into the lookup, and stop caching a failed load in _cachedBasket so a retry can succeed.