ShoppingSystem is an enterprise-level e-commerce microservice application built with .NET 10 and C#.
The project follows:
- Domain-Driven Design (DDD)
- Clean Architecture
- CQRS Pattern
- Microservice Architecture
- Event-Driven Architecture
The system uses an API Gateway with YARP as the entry point and communicates between services using RabbitMQ message queues.
Project Status: Under Development
ShoppingSystem is currently under active development. New features, improvements, and architectural enhancements are being added continuously.
As the project is evolving, there may still be bugs, incomplete features, or areas that require further refinement. The codebase is continuously being improved with the goal of building a scalable, maintainable, and production-ready microservice architecture.
If you find any issues, have suggestions, or would like to contribute, please feel free to open an issue or fork the repository. Contributions and feedback are welcome and help improve the project as it continues to evolve.
ShoppingSystem follows Microservice Architecture combined with Clean Architecture and Domain-Driven Design (DDD) principles.
The solution is organized into separate projects, where each project has a specific responsibility.
ShoppingSystem.Microservice
│
├── ShoppingSystem.Microservice.Gateway
│ └── YARP Reverse Proxy
│
├── ShoppingSystem.Microservice.Domain
│ ├── Aggregates
│ ├── Entities
│ ├── Value Objects
│ └── Domain Events
│
├── ShoppingSystem.Microservice.Application
│ ├── CQRS Commands
│ ├── CQRS Queries
│ ├── MediatR Handlers
│ ├── DTOs
│ └── Validators
│
├── ShoppingSystem.Microservice.Infrastructure
│ ├── Entity Framework Core
│ ├── Repository Pattern
│ ├── Unit Of Work
│ ├── Database Factory
│ ├── RabbitMQ
│ └── Notification Abstractions
│
├── ShoppingSystem.Microservice.Infrastructure.Identity
│ ├── ASP.NET Core Identity
│ ├── JWT Authentication
│ ├── Refresh Tokens
│ └── OAuth Authentication
│
├── ShoppingSystem.Microservice.Notification.Email
│ ├── Email Service
│ ├── MailKit Integration
│ ├── Email Templates
│ └── Email Configuration
│
└── ShoppingSystem.Microservice.Notification.Sms
├── SMS Service
├── Twilio Integration
├── SMS Templates
└── SMS Configuration
This section explains how to configure, run, and use the ShoppingSystem Microservice application.
Before running the application, make sure all required dependencies are installed and infrastructure services are available.
Before starting the project, install the following tools:
| Tool | Version |
|---|---|
| .NET SDK | .NET 10 |
| Docker Desktop | Latest |
| SQL Server | 2025 or Docker SQL Server Container |
| RabbitMQ | 3.x |
| Git | Latest |
| Visual Studio / Rider / VS Code | Latest |
- SQL Server Management Studio (SSMS)
- Docker Desktop
- Postman
- Navicat or another database management tool
ShoppingSystem requires several infrastructure services to run correctly.
The following dependencies are used:
| Service | Purpose |
|---|---|
| Database Provider | Application database storage |
| Identity Database | Authentication and user management (SQL Server only) |
| RabbitMQ | Event-driven communication between services |
| Mail Container | Email testing environment |
All infrastructure services can be started using Docker Compose.
The project provides Docker-based infrastructure for local development.
The infrastructure includes:
- SQL Server container
- RabbitMQ container
- Mail testing container
Example:
docker run -e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=YourStrong@Password123" \
-p 1433:1433 \
--name shopping-system-sqlserver \
-d mcr.microsoft.com/mssql/server:2025-latest--hostname shopping-system-rabbitmq \
--name shopping-system-rabbitmq \
-p 5672:5672 \
-p 15672:15672 \
rabbitmq:3-managementdocker run -d \
--name shopping-system-mailhog \
-p 1025:1025 \
-p 8025:8025 \
mailhog/mailhogThis is the UI for MailHog when you open it in the browser:
ShoppingSystem uses ASP.NET Core configuration providers to manage application settings.
Configuration can be provided through:
appsettings.jsonappsettings.Development.json- User Secrets
- Environment Variables
ShoppingSystem supports configurable database providers for the main application, allowing the system to work with different database engines based on deployment requirements.
Supported Providers SQL Server PostgreSQL Oracle MySQL In-Memory Database (for testing and development scenarios) Selecting a Database Provider
The active database provider is configured using User Secrets.
For PostgreSQL:
dotnet user-secrets set "Database:Provider" "PostgresDb"
For SQL Server:
dotnet user-secrets set "Database:Provider" "SqlServer"
For MySQL:
dotnet user-secrets set "Database:Provider" "MySql"
You should also configure the corresponding connection string in your User Secrets:
dotnet user-secrets set "ConnectionStrings:ShoppingSystem_Microservice" "<your_connection_string>" Important: Provider-Specific Migrations
Entity Framework Core migrations are database-provider specific. A migration generated for one provider (for example, SQL Server) cannot be reused for another provider (such as PostgreSQL or MySQL).
Each supported provider should maintain its own migration history in a separate folder. A recommended structure is:
Infrastructure
└── Persistence
└── Migrations
├── SqlServer
├── Postgres
├── Oracle
├── MySql
└── InMemory
When switching to a different database provider:
Set the desired provider using User Secrets. Generate migrations for that provider only. Apply the migrations to the corresponding database.
Keeping migrations separated ensures that provider-specific features (such as SQL functions, filtered indexes, generated columns, and data types) are generated correctly and remain compatible with each database engine.
Important: The IdentityConnectionStringName must always point to a SQL Server database because the Identity service uses ASP.NET Core Identity with SQL Server as its storage provider.
Current configuration:
{
"Database": {
"Provider": "SqlServer",
"ConnectionStringName": "ShoppingSystem_Microservice",
"IdentityConnectionStringName": "ShoppingSystem_Microservice_Identity"
}
}
{
"ConnectionStrings": {
"ShoppingSystem_Microservice": "Your connection string",
"ShoppingSystem_Microservice_Identity": "Your connection string"
}ShoppingSystem uses RabbitMQ as the message broker for event-driven communication between microservices.
RabbitMQ is responsible for:
- Publishing integration events
- Consuming messages from queues
- Asynchronous communication between services
- Decoupling microservices
The RabbitMQ configuration is defined in appsettings.json:
{
"RabbitMq": {
"HostName": "localhost",
"UserName": "guest",
"Password": "guest"
}
}ShoppingSystem uses MailKit for sending email notifications.
For local development and testing, the project uses a mail testing container that provides an SMTP server. Emails are captured locally and can be viewed through a browser interface without sending real emails.
The email configuration is defined in appsettings.json:
{
"EmailSettings": {
"Host": "localhost",
"Port": 1025,
"From": "test@local.com",
"DisplayName": "ShoppingSystem.Support",
"UseSsl": false
}
}After starting the required Docker dependencies, you can access the web interface (GUI) at:
Before running the application, make sure all required infrastructure dependencies are available:
- Database server
- RabbitMQ
- Email testing service
The application requires the database to be configured and migrations to be applied before starting the services.
If you want to use the YARP API Gateway, you must run both the gateway and the required application services together.
The API Gateway acts as the single entry point for client requests and routes incoming traffic to the appropriate microservices.
After starting:
ShoppingSystem.Microservice.Gateway- Required backend services
You should send your API requests through the gateway instead of calling the services directly.
https://localhost:7233/api/1/Address/GetAll?Criteria.PageSize=10&Criteria.PageNumber=1
Or:
https://localhost:7233/health
ShoppingSystem includes automated tests to verify the correctness and reliability of the application.
The test projects cover different layers of the system, including:
- Domain logic
- Application services
- Business rules
- Integration scenarios
ShoppingSystem is continuously evolving. The following features and improvements are planned for future development.
| Category | Planned Improvement |
|---|---|
| Infrastructure | Fully containerize the complete application using Docker |
| Infrastructure | Containerize all microservices |
| Infrastructure | Containerize infrastructure dependencies |
| Infrastructure | Create a complete Docker Compose environment for local development |
| Infrastructure | Improve deployment consistency across environments |
| Database | Add MongoDB for document-based data |
| Database | Store media metadata and flexible product/catalog data in MongoDB |
| Database | Store activity logs and audit data in MongoDB |
| Storage | Integrate MinIO for object/file storage |
| Storage | Store product images, videos, and other media files in MinIO |
| Storage | Store file metadata and object references in the database |
| Storage | Implement secure file upload and download using MinIO |
| Microservices | Migrate the modular monolith to independently deployable microservices |
| Deployment | Add Kubernetes deployment support |
| Deployment | Add container orchestration |
| Deployment | Improve environment-based configuration management |
| Performance | Add Redis caching support |
| Performance | Cache frequently accessed data |
| Performance | Improve API response times |
| Performance | Reduce unnecessary database queries |
| Performance | Implement distributed caching between services |
| Performance | Add response caching where applicable |
| Observability | Integrate Prometheus for metrics collection |
| Observability | Configure Grafana dashboards for real-time monitoring |
| Observability | Monitor application, infrastructure, and database metrics |
| Observability | Implement centralized logging |
| Observability | Add distributed tracing across microservices |
| Security | Implement API rate limiting |
| Security | Protect APIs against excessive requests |
| Security | Prevent abuse and unnecessary resource consumption |
| Security | Add configurable rate limiting policies |
| Testing | Complete Unit Test coverage across all layers |
| Testing | Add Integration Tests for APIs and database operations |
| Testing | Implement End-to-End (E2E) testing |
| Testing | Add Performance and Load Testing |
| Testing | Increase overall code coverage |
| CI/CD | Automate testing within CI/CD pipelines |
| CI/CD | Automate Docker image building and publishing |
| CI/CD | Automate deployments to staging and production |
| Documentation | Expand API documentation and developer guides |
| Documentation | Improve architecture and deployment documentation |