junioranheu/mongo-and-redis-playground-api

1. Overall shape

- This is a small .NET solution organized in a layered/clean-architecture style: API → Application → Domain ← Infrastructure.

- The domain layer owns the core model and abstractions; infrastructure provides MongoDB and Redis implementations; the API hosts HTTP endpoints.

2. API layer

- MongoRedisPlayground.API is the entry point and web host (Program.cs).

- It contains two controllers: HeroesController and HeroAttributesController, which expose the application’s capabilities over HTTP.

- DependencyInjection.cs and DependencyAppConfiguration.cs are used to wire up the lower layers and configuration.

3. Application layer

- MongoRedisPlayground.Application contains the use-case services: HeroService and HeroAttributeService.

- This layer coordinates business operations and acts as the boundary between controllers and persistence/caching.

- It depends on abstractions from the domain rather than concrete storage implementations.

4. Domain model

- MongoRedisPlayground.Domain holds the core entities: Hero, HeroAttribute, and Ability.

- It also defines domain enums such as HeroRoleEnum and AttackTypeEnum, which encode business vocabulary.

- Shared constants live here too, including cache key definitions in CacheKeys.

5. Domain contracts

- The domain defines repository interfaces like IHeroRepository and IHeroAttributeRepository.

- It also defines ICacheService, keeping caching as an abstract capability rather than tying business logic to Redis directly.

- This makes the application layer independent of MongoDB/Redis implementation details.

6. Infrastructure layer

- MongoRedisPlayground.Infrastructure provides the concrete technical adapters.

- Repositories/HeroRepository.cs and Repositories/HeroAttributeRepository.cs implement the domain repository interfaces.

- Services/RedisCacheService.cs implements the cache abstraction, likely using Redis as the backing store.

7. Persistence boundary

- Persistence/MongoDbContext.cs and Persistence/MongoDbSettings.cs indicate MongoDB is the primary data store.

- The repositories are the main boundary where application/domain objects are translated to MongoDB documents and back.

- Configuration for the database connection is separated into settings rather than embedded in code.

8. Caching boundary

- Redis is a second external system, represented by the infrastructure cache service.

- Cache key naming is centralized in the domain constants, suggesting cache usage is part of the business flow rather than an ad hoc implementation detail.

- The likely pattern is controller request → application service → repository/cache abstraction → MongoDB and/or Redis.

9. Request/data flow

- A client calls an API controller.

- The controller delegates to HeroService or HeroAttributeService.

- The service uses repository interfaces and cache abstraction defined in the domain.

- Infrastructure classes fulfill those calls against MongoDB and Redis.

10. Dependency direction

- Dependencies point inward: API and Infrastructure depend on Application/Domain abstractions.

- Domain does not depend on the web, MongoDB, or Redis.

- This separation is the main architectural boundary to show in a diagram.

11. Solution composition

- The solution file MongoRedisPlayground.slnx ties together four projects: API, Application, Domain, and Infrastructure.

- Each project has its own .csproj, reinforcing the modular boundaries.

12. What to highlight in a diagram

- Show controllers at the edge, application services in the middle, domain entities/interfaces at the core, and MongoDB/Redis as external systems reached only through infrastructure.

- The two primary functional areas are Heroes and Hero Attributes, each with parallel controller/service/repository paths.