jbw/TooBigToFailBurgerShop

This system is a distributed microservices application for a burger shop, enabling customers to manage shopping baskets and place orders through a Blazor web interface. It coordinates order processing across multiple services using Dapr for state management and pub/sub, MassTransit with RabbitMQ for messaging, and Marten for event sourcing to ensure data consistency. The architecture includes specific services for basket management, order creation, and saga-based state tracking, all supported by PostgreSQL and MongoDB for persistence.

The application now includes the Bootstrap CSS framework (bootstrap.min.css) in the static web assets, providing a complete set of responsive layout, form, and component styles. The stylesheet is configured with a custom color palette—using red (\#D62304) as the primary brand color, green (\#1B8737) for success states, and brown (\#663C2D) for informational elements—ensuring the UI reflects the Burgers brand identity.

src/web/Burgers.WebSPA/wwwroot · high confidence

The application now includes the underlying data structures and client-side services required to manage a customer's shopping basket and place orders. New classes \BasketItem\ and \CustomerBasket\ define the basket structure, while \BasketService\ enables retrieving the current basket and adding items (currently hardcoded as 'Juicy burger') to it via the \/api/basket\ endpoint. Additionally, \Order\ and \OrdersService\ provide the capability to submit a new order to the \/api/orders\ endpoint. Both services are integrated with the authentication system, automatically attaching the access token to HTTP requests.

src/web/Burgers.WebSPA/Data · high confidence

The Ordering.Messages package now includes a set of new message contracts (CreateBurgerOrder, SubmitBurgerOrder, ProcessBurgerOrder, BurgerOrderProcessed, BurgerOrderFaulted, and OrderSubmitted) within the TooBigToFailBurgerShop.Ordering.Contracts namespace. These messages, which implement MassTransit's CorrelatedBy\<Guid\> interface, define the data structures for the ordering workflow and are intended to support distributed transaction and saga-based communication patterns.

src/services/Ordering/Ordering.Messages · high confidence

The Ordering.State service now includes a saga implementation using MassTransit and Automatonymous to manage the state of burger orders. A new state instance tracks the order ID, correlation ID, and current state, while the state machine defines transitions for submitting an order, waiting for processing, and finalizing as either processed or faulted based on domain events.

src/services/Ordering/Ordering.State · high confidence

The Ordering API now exposes endpoints to create and retrieve orders, implementing a distributed workflow where order creation triggers a message to the 'burgers-pubsub' via Dapr. The system ensures idempotency for order creation requests using a MongoDB-backed repository to track request IDs, preventing duplicate processing. Additionally, order data is archived in MongoDB for query purposes, and the service is configured with Serilog for structured logging, OpenTelemetry tracing to Jaeger, and MassTransit for RabbitMQ integration.

src/services/Ordering/Ordering.API · high confidence

The ordering service now includes the foundational infrastructure for data persistence and request safety. A new \BurgerShopContext\ is introduced, configured to connect to a PostgreSQL database using the Npgsql provider, along with the corresponding Entity Framework Core migration files to manage schema evolution. Additionally, an idempotency mechanism has been added to prevent duplicate order processing; this includes an \IdempotentCommand\ wrapper, a handler that delegates to the MediatR pipeline, and a \RequestManager\ interface to track and validate incoming requests.

src/services/Ordering/Ordering.Infrastructure · high confidence

The \src\ area is initialized with the core solution structure, including the \TooBigToFailBurgerShop.sln\ file that defines the ordering and basket service projects. Docker infrastructure is added via \docker-compose.yml\ and \docker-compose.override.yml\, configuring services for Keycloak, Redis, MongoDB, RabbitMQ, and Dapr sidecars. The ordering service's messaging layer is implemented using MassTransit with RabbitMQ, featuring an \EventProducer\ for domain events and consumer configuration. On the frontend, the \Burgers.WebSPA\ includes a new \MenuItemCard\ Razor component for displaying menu items.

src · high confidence

This change introduces the core pages and layout for the Burger Shop web application, built on Blazor Server. It includes an error handling page, a home page, and a user profile view that displays authenticated claims. The application now supports OpenID Connect authentication via dedicated login and logout pages, and provides ordering functionality with a basket view and an order creation page that allows users to add menu items to their basket.

src/web/Burgers.WebSPA/Pages · high confidence

This change introduces the initial version of the Burgers WebSPA, a Blazor Server-side application that provides the user interface for the ordering system. It implements authentication via OpenID Connect (using Keycloak) with cookie-based sessions, allowing users to log in and out. The application features a main layout with a navigation menu linking to Home and Order pages, and includes a basket link in the top bar. It configures HTTP clients to communicate with the Ordering and Basket APIs through a gateway, and integrates distributed tracing via OpenTelemetry and Jaeger for observability.

src/web/Burgers.WebSPA · high confidence

The Ordering service now supports event sourcing via Marten. This change adds the \Ordering.Persistence.MartenDb\ library, which provides an \EventStoreBuilder\ and \EventsRepository\ to configure the Marten document store and register the \IEventsRepository\ implementation. The repository implements \AppendAsync\ to persist aggregate events using Marten's stream capabilities, enabling the service to store and manage domain events.

src/services/Ordering/Ordering.Persistence.MartenDb · high confidence

The Ordering State Service is introduced to manage saga state for burger orders using MassTransit and PostgreSQL. It enables Dapr pub/sub interoperability by registering a custom CloudEvent deserializer that unwraps Dapr CloudEvents for MassTransit consumers. The service configures RabbitMQ as the transport, implements an in-memory outbox for reliability, and persists saga state (BurgerOrderStateInstance) in PostgreSQL via Entity Framework Core, including database migrations for the saga table and unique order ID constraints.

src/services/Ordering/Ordering.StateService · high confidence

The CreateOrder.Consumer service now handles incoming burger order requests via MassTransit, ensuring data consistency across PostgreSQL (order persistence), MongoDB (order ID deduplication), and event sourcing (domain event publishing). It includes a consumer that validates order uniqueness before creating the order aggregate and persisting it, alongside a separate consumer that archives order creation events. The service is configured with Serilog for structured logging, OpenTelemetry tracing via Jaeger, and database retry policies to handle transient failures.

src/services/Ordering/CreateOrder.Consumer · high confidence

The ProcessOrder.Consumer service now handles incoming burger orders using MassTransit routing slips to execute the \ProcessBurgerOrderActivity\ with built-in compensation (rollback) support. This change introduces a resilient workflow where order processing is decoupled via RabbitMQ, featuring an in-memory outbox to prevent duplicate events, configurable message retry intervals, and a concurrency limit of 8 messages per consumer. Additionally, the service is configured for distributed observability by exporting traces to Jaeger, allowing users to track the lifecycle of an order from consumption through activity execution and completion or fault handling.

src/services/Ordering/ProcessOrder.Consumer · high confidence

The Ordering.Domain.Core module now provides the foundational building blocks for Domain-Driven Design and event sourcing. This includes base classes for Entities and Aggregate Roots with versioning, a mechanism for tracking and clearing Domain Events, and a dedicated EventsService that decouples event dispatching from data persistence. Additionally, the module introduces a ValueObject abstraction with automatic immutability validation and equality checks, along with a ValidationException class for structured error handling.

src/services/Ordering/Ordering.Domain.Core · high confidence

This change introduces the Basket.API service, exposing HTTP endpoints to retrieve, update, and delete customer baskets. The implementation uses Dapr for state management, persisting basket data to a Dapr state store named 'burgers-statestore' via the BasketRepository, and registers the necessary controllers and services in the ASP.NET Core startup configuration.

src/services/Basket · high confidence

The Ordering service now includes a README detailing how to create and apply database migrations for Orders, Saga State, and Order events, alongside a new SQL script that defines the PostgreSQL tables and functions required for the Marten event store (mt\_streams, mt\_events, mt\_event\_progression).

src/services/Ordering/Migrations · high confidence

The infrastructure layer now defines consumer configurations for CreateBurgerOrder and OrderArchiver consumers. These configurations limit concurrent message processing to eight, implement a retry strategy with intervals of 100, 200, 500, 800, and 3000 milliseconds, and enable an in-memory outbox to prevent duplicate event publishing and defer messages until transaction completion.

src/services/Ordering/CreateOrder.Consumer/Infrastructure · high confidence

Added integration test infrastructure for the Ordering service; Added integration tests for Order API endpoints; Added unit tests for ValueObject immutability and equality.

The project is initialized with a .NET 5 target framework across all services and the web application. The dependency structure introduces Dapr (v1.1.2) for the Basket API, MassTransit (v7.1.8) with RabbitMQ for distributed messaging in the Ordering services, and OpenTelemetry for distributed tracing. Persistence is configured with Entity Framework Core (v5.0.6) and PostgreSQL (Npgsql v5.0.5) for the Ordering API and State Service, while Marten (v4.0.0-alpha.4) is added for event sourcing in the Ordering persistence layer. The web frontend uses Blazor WebAssembly with authentication support, and the entire solution includes code analysis tools (codecracker) and Docker build tooling.

(dependencies) · high confidence

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

• CAI 56 → 54 (-1.9)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 70 → 68 (-2.6)
• Architecture 86 → 86 (+0.0)
• Maturity 55 → 55 (+0.0)
• Readiness 55 → 50 (-5.3)
• Security 72 → 73 (+1.4)
• Domain Modelling 56 → 64 (+7.7)
• Event-Driven 100 → 100 (+0.0)
• Accessibility 53 → 51 (-1.6)

• Bounded contexts not declared
• Coverage not measured — analyzer environment
• High IaC: DS-0002 (src/services/Ordering/Ordering.IntegrationTests/Dockerfile)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Inconsistent spelling of 'Immutability' in type names. One is spelled 'Immutabilty' (missing 'i') and the other 'Immutabilty' (also missing 'i'). While they are distinct types, the shared root 'Immutabilty' suggests a systematic typo in the codebase's naming convention for this concept.
• Inconsistent spelling of 'Properties' in method names. One method is named 'AllProperiesAreEqual' (missing 'e' in Properties) while the other is 'ValueObjectAreEqual'. The typo 'Properies' should be 'Properties'.
• Low IaC: DS-0026 (src/services/Ordering/Ordering.IntegrationTests/Dockerfile)
• Medium CVE: Microsoft.Data.SqlClient 2.0.0
• Medium CVE: SharpCompress 0.23.0
• Medium CVE: SharpCompress 0.23.0
• Medium CVE: System.Data.SqlClient 4.8.1
• Redundant/Overlapping Intent: These three types all represent actions on a burger order involving an OrderId, OrderDate, and CorrelationId (in some cases). The naming convention is inconsistent: 'Create' implies initial submission, 'Process' implies handling, and 'Submit' implies finalizing. However, they all share the same core identity (OrderId) and temporal data (OrderDate), making it unclear if they represent distinct lifecycle stages or are just different names for the same logical operation. Specifically, 'ProcessBurgerOrder' and 'SubmitBurgerOrder' are semantically ambiguous relative to each other.
• …and 3 more

• Documentation: no architecture or design documentation (README.md)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (11–12 lines × 2) (src/services/Ordering/CreateOrder.Consumer/Program.cs)
• Duplicated block (15–16 lines × 2) (src/services/Ordering/Ordering.StateService/Application/Extensions/MassTransitExtension.cs)
• Duplicated block (16 lines × 3) (src/services/Ordering/CreateOrder.Consumer/Infrastructure/CreateBurgerOrderConsumerDefinition.cs)
• Duplicated block (23–24 lines × 2) (src/services/Ordering/CreateOrder.Consumer/Program.cs)
• Duplicated block (5 lines × 2) (src/services/Ordering/Ordering.Persistence.Mongo/EventHandlers/OrderArchiveByIdHandler.cs)
• Duplicated block (7 lines × 2) (src/web/Burgers.WebSPA/Data/BasketService.cs)
• End-of-life runtime: .NET net5.0
• High IaC: WD-COMPOSE-0002 (src/docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (src/docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (src/docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (src/docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (src/docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (src/docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (src/docker-compose.yml)
• High IaC: WD-DOCKER-0013 (src/services/Basket/Basket.API/Dockerfile)
• High IaC: WD-DOCKER-0013 (src/services/Basket/Basket.API/Dockerfile)
• High IaC: WD-DOCKER-0013 (src/services/Ordering/CreateOrder.Consumer/Dockerfile)
• …and 68 more

• Unchanged — 6 HTTP endpoints

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

jbw/TooBigToFailBurgerShop 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.