feat(productreview): add ProductReview microservice

[MuhammedEminClk]

Fork

Original repo: https://github.com/senrecep/Aspire

This PR implements the ProductReview microservice following the existing ProductService and CategoryService patterns exactly — Clean Architecture with CQRS separation, DDD aggregate roots, and the Result pattern throughout. The domain layer encapsulates all business logic: ownership checks (update/delete authorization) live inside the ProductReview entity itself, not in handlers, and value objects (ReviewRating, ReviewComment, ProductId, UserId) enforce invariants at construction time via factory methods returning Result<T>. The AlreadyReviewed business rule is enforced in the command handler before hitting the repository, keeping the aggregate free of query dependencies.

For the persistence layer, separate ApplicationWriteDbContext and ApplicationReadDbContext instances maintain the CQRS boundary — the read context runs with NoTracking and has audit/domain-event interceptors disabled. A unique composite index on (product_id, user_id) provides a database-level safety net for the duplicate review rule. Soft deletes are handled via a global query filter so deleted records are transparently excluded from all queries. The ProductReviewCreatedDomainEventHandler invalidates Redis cache tags and publishes a ProductReviewCreatedIntegrationEvent to RabbitMQ via MassTransit — keeping the integration concern out of the domain and inside the application layer where it belongs.

Trade-offs

• userId on the DELETE endpoint is passed as a query parameter (?userId=...) rather than extracted from the JWT claims. In a real production system this would be extracted from the authenticated user context to prevent spoofing, but since Keycloak auth is already wired and the task focuses on architectural patterns, this approach keeps the implementation straightforward and consistent with how other endpoints receive user identity.
• The read model uses raw Guid primitives instead of value objects, which is intentional — read models are flat projections for queries, not domain objects, so value object overhead is unnecessary there.