sagizod/eshoponcontainers

Purpose and execution

eShopOnContainers is a .NET Core 3.1 reference e-commerce system demonstrating independently deployable, containerized microservices. Local composition starts from src/docker-compose.yml; the solution entry is src/eShopOnContainers-ServicesAndWebApps.sln. Each service is an ASP.NET Core process with its own Docker image and Program.cs/Startup.cs host boundary.

Client and edge layer

Browser clients are server-rendered MVC and an Angular SPA; a status site and webhook demo client are auxiliary entry points.

• MVC storefront: src/Web/WebMVC/Program.cs, src/Web/WebMVC/Controllers/CatalogController.cs

• Angular SPA hosted by ASP.NET Core: src/Web/WebSPA/Client/main.ts, src/Web/WebSPA/Startup.cs

• Separate mobile and web shopping BFFs aggregate downstream basket, catalog, and ordering calls: src/ApiGateways/Web.Bff.Shopping/aggregator/Startup.cs, src/ApiGateways/Mobile.Bff.Shopping/aggregator/Controllers/OrderController.cs

• Envoy gateway configurations define edge routing per client type: src/ApiGateways/Envoy/config/webshopping/envoy.yaml, src/ApiGateways/Envoy/config/mobileshopping/envoy.yaml.

Identity and service communication

Identity.API is the OAuth/OIDC identity boundary used by clients and protected APIs. BFFs and web applications propagate authorization via HTTP delegating handlers; internal service reads also expose gRPC contracts where present.

• Identity host/configuration: src/Services/Identity/Identity.API/Startup.cs, src/Services/Identity/Identity.API/Configuration/Config.cs

• Authorization propagation: src/ApiGateways/Web.Bff.Shopping/aggregator/Infrastructure/HttpClientAuthorizationDelegatingHandler.cs

• gRPC boundaries: src/Services/Basket/Basket.API/Proto/basket.proto, src/Services/Catalog/Catalog.API/Proto/catalog.proto, src/Services/Ordering/Ordering.API/Proto/ordering.proto.

Catalog and basket domains

Catalog owns product, brand/type, stock, and picture data through EF Core; Basket owns per-customer carts in Redis. Basket checkout publishes an integration event rather than synchronously creating an order.

• Catalog HTTP/gRPC API and persistence: src/Services/Catalog/Catalog.API/Controllers/CatalogController.cs, src/Services/Catalog/Catalog.API/Infrastructure/CatalogContext.cs

• Basket API and Redis repository: src/Services/Basket/Basket.API/Controllers/BasketController.cs, src/Services/Basket/Basket.API/Infrastructure/Repositories/RedisBasketRepository.cs

• Checkout event contract: src/Services/Basket/Basket.API/IntegrationEvents/Events/UserCheckoutAcceptedIntegrationEvent.cs.

Ordering workflow and payment saga

Ordering is the primary DDD/CQRS subsystem: commands enter its API, MediatR-style behaviors enforce validation, transactionality, and idempotency, and aggregates persist orders/buyers. It consumes checkout, payment, and stock events, emits order-status events, and drives a distributed workflow. Payment reacts after stock confirmation; a background worker manages the grace period; SignalR broadcasts lifecycle updates.

• API commands/workflow: src/Services/Ordering/Ordering.API/Application/Commands/CreateOrderCommandHandler.cs, src/Services/Ordering/Ordering.API/Application/IntegrationEvents/EventHandling/UserCheckoutAcceptedIntegrationEventHandler.cs

• Domain and persistence: src/Services/Ordering/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs, src/Services/Ordering/Ordering.Infrastructure/OrderingContext.cs

• Payment, background, and notifications: src/Services/Payment/Payment.API/IntegrationEvents/EventHandling/OrderStatusChangedToStockConfirmedIntegrationEventHandler.cs, src/Services/Ordering/Ordering.BackgroundTasks/Tasks/GracePeriodManagerTask.cs, src/Services/Ordering/Ordering.SignalrHub/NotificationHub.cs.

Eventing and external notifications

The shared EventBus abstracts RabbitMQ or Azure Service Bus. EF-backed integration-event logs support reliable publication alongside service database transactions. Catalog price/stock changes and ordering statuses fan out asynchronously to basket, payment, catalog, SignalR, and webhook subscribers. Webhooks stores subscriptions and delivers outbound HTTP callbacks.

• Bus abstractions/transports: src/BuildingBlocks/EventBus/EventBus/Abstractions/IEventBus.cs, src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.cs, src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.cs

• Transactional event log: src/BuildingBlocks/EventBus/IntegrationEventLogEF/Services/IntegrationEventLogService.cs

• Webhook boundary: src/Services/Webhooks/Webhooks.API/Controllers/WebhooksController.cs, src/Services/Webhooks/Webhooks.API/Services/WebhooksSender.cs.

Infrastructure and deployment

The normal runtime is Docker Compose; Kubernetes Helm charts deploy the same service topology, including Envoy gateways, ingress, SQL, Redis, RabbitMQ, and shared secrets. Azure templates provision SQL, Redis, Service Bus, Cosmos DB, and catalog storage. ELK Compose assets provide centralized logging.

• Composition/deployment: src/docker-compose.yml, deploy/k8s/helm/app.yaml, deploy/k8s/helm/deploy-all.sh

• Cloud resources: deploy/azure/az/sql/sqldeploy.json, deploy/azure/az/redis/redisdeploy.json, deploy/azure/az/servicebus/sbusdeploy.json

• Observability stack: src/docker-compose.elk.yml, deploy/elk/logstash/pipeline/logstash.conf.