.NET 8 Microservices Architecture

Context

The project architecture represents a .NET 8 microservices ecosystem with different service styles working together. Shopping.Web and Discount.Grpc follow a traditional layered shape, Ordering uses Clean Architecture, and Catalog plus Basket use Vertical Slice organization.

This work was necessary because a distributed system can look modern while still hiding coupling between services, databases, messaging, and gateway behavior. The goal was to make the system boundaries explicit enough for review, onboarding, and future production hardening.

Approach

I classified each service by its primary architectural pattern instead of forcing one style across the whole solution. This keeps the analysis pragmatic: the web front end, gRPC discount service, ordering workflow, and catalog or basket features have different reasons to be structured differently.

The review focused on dependency direction, service responsibility, data ownership, and communication flow. YARP acts as the gateway boundary, gRPC supports internal synchronous calls, and RabbitMQ with MassTransit supports asynchronous integration between business capabilities.

Technical points

• Identified Shopping.Web and Discount.Grpc as N-Layer services based on presentation, business, and data access responsibilities.
• Mapped Ordering as Clean Architecture with Domain, Application, Adapter, and Infrastructure responsibilities.
• Mapped Catalog and Basket as Vertical Slice services where feature folders own commands, queries, validation, persistence, and endpoint behavior.
• Reviewed persistence choices across PostgreSQL, SQL Server, Redis, SQLite, Marten, and EF Core.
• Highlighted service communication through YARP, Refit, gRPC, RabbitMQ, and MassTransit.
• Checked architectural risks around gateway validation, service-to-service coupling, and distributed observability.

Result

The architecture map turns a multi-pattern solution into an understandable engineering model. It helps a team see where dependency rules matter most, where feature ownership is local to a slice, and where production readiness depends on gateway policy, messaging reliability, and observability.

The main outcome is not adding more abstraction. It is making the current architecture easier to reason about, review, and evolve without accidentally mixing responsibilities across service boundaries.

GitHub project

Review the related implementation work and project repositories on GitHub.