spaki/Pluto

Pluto is a proof-of-concept e-commerce application built with ASP.NET Core and React. It implements a Domain-Driven Design architecture using CQRS and Event Sourcing, managing users, products, and orders through a structured backend. The system handles authentication, data persistence via SQL Server, and domain event processing to coordinate business logic.

The Pluto.Bus module now includes an InMemoryBus class that implements the IMediatorHandler interface. This class wraps the MediatR library to handle sending commands, processing request commands that return results, and publishing domain events, while also persisting events to a stored event repository.

Pluto.Bus · high confidence

New command handlers have been introduced to support the creation, update, and deletion of products and users, as well as the full lifecycle of an order (create, add/remove products, approve, commit, and cancel). These handlers implement the CQRS pattern using MediatR, allowing the business layer to return data (such as the created Order entity) alongside standard side-effect commands, facilitating data traffic between the business and API layers.

Pluto.Domain/Handlers/Commands · high confidence

The Pluto.Utils library now includes new static utility classes for encryption and data validation. The new Cryptography class provides Encrypt and Decrypt methods using TripleDES encryption with a hardcoded key, while the Validation class offers extension methods for checking null, empty, or invalid email values, allowing developers to easily validate and inspect object properties.

Pluto.Utils · high confidence

New event handler classes have been introduced to process domain events for orders, products, and users. Specifically, OrderEventHandler, ProductEventHandler, and UserEventHandler now listen for their respective domain events (e.g., CreateOrderEvent, AddProductEvent, CreateUserEvent). A shared CommandHandler base class was also added to manage unit of work and notifications. These handlers currently contain placeholder implementations, establishing the infrastructure for handling these domain events.

Pluto.Domain/Handlers/Events · high confidence

The repository layer is introduced with a generic \CrudRepository\ base class and specific implementations for \Order\, \Product\, \User\, and \StoredEvent\. Database mapping is handled via a new \DbEntityConfiguration\ pattern that automatically registers entity configurations using \ModelBuilderExtensions\. The \MainDbContext\ and \EventStoreSQLContext\ are configured to use these mappings. Initial migration scripts create the \Order\, \OrderItem\, \PictureUrl\, \Product\, and \User\ tables, along with a \StoredEvent\ table for the event store. The \Order\ table is updated to include \CustomerId\ and \EditorId\ foreign keys, and the \User\ table includes a \Profile\ field.

Pluto.Repository · high confidence

The Pluto project is introduced as a proof-of-concept for an e-commerce application, featuring an ASP.NET Core backend and a React frontend. The backend implements Domain-Driven Design (DDD), CQRS, and Event Sourcing, utilizing SQL Server with Entity Framework, MediatR, and .NET Core's native dependency injection. The frontend is a React single-page application. The solution file defines five main projects: Domain, Repository, Bus, API, and Utils, alongside a README detailing the architecture and setup instructions.

(repo-wide) · high confidence

The API now supports user authentication via JWT tokens, allowing users to log in and receive access tokens for subsequent requests. The \AuthController\ handles login and token generation, while the \UserControl\ extracts user identity from the current HTTP context. Additionally, the \UserController\ exposes endpoints for creating, updating, and deleting users, as well as changing passwords. The \OrderController\ provides endpoints for managing orders, including adding/removing products and approving/canceling orders. The \ProductController\ offers CRUD operations for products. The \AuthenticatedController\ base class enforces bearer token authentication on protected endpoints.

Pluto.API, Pluto.Domain · high confidence

The repository introduces the foundational .NET project structure, defining five new project files (Pluto.API, Pluto.Bus, Pluto.Domain, Pluto.Repository, and Pluto.Utils) with their respective package references and target frameworks.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 45 → 46 (+0.7)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 84 → 83 (-0.7)
• Architecture 84 → 85 (+0.6)
• Maturity 58 → 58 (+0.0)
• Readiness 18 → 18 (-0.3)
• Security 72 → 73 (+1.6)
• Domain Modelling 99 (new)
• Event-Driven 100 → 100 (+0.0)

• High CVE: Microsoft.NETCore.App 2.2.0
• High CVE: Microsoft.NETCore.App 2.2.0
• Inconsistent spelling of 'Bearer' in the authentication-related types. 'BaererAuthorizeAttribute' uses a non-standard spelling ('Baerer' instead of 'Bearer').
• Inconsistent spelling of 'Cancelled' vs 'Canceled'. The codebase uses 'Canceled' in 'Pluto.Domain.Models.Order.Canceled', but British spelling 'Cancelled' is often preferred in this codebase (e.g., 'Pluto.Domain.Models.Order.Commited' suggests a mix of errors or variants).
• Inconsistent spelling of 'Committed' and 'Cancelled' in the Order model properties. 'Commited' is a misspelling of 'Committed', and 'Canceled' uses one 'l' while 'Commited' (if intended as committed) or other status properties show spelling variations.
• Low cohesion: OrderController (LCOM4 6) (Pluto.API/Controllers/OrderController.cs)
• Medium CVE: Microsoft.AspNetCore.App 2.2.0
• Medium CVE: Microsoft.NETCore.App 2.2.0
• Medium CVE: System.Data.SqlClient 4.6.0
• No exposed public API
• The README mentions architecture topics like CQRS, Event Sourcing, Domain Events but does not link them or explain how they are implemented in code. (README.md)
• early-stage repository — too few commits for a meaningful bus factor
• early-stage repository — too little history to judge knowledge freshness
• git history depth insufficient
• git history depth insufficient
• redundant comment (Pluto.API/Controllers/OrderController.cs)
• redundant comment (Pluto.Domain/Handlers/Commands/ProductCommandHandler.cs)

• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• End-of-life runtime: .NET netcoreapp2.2
• High CVE: Microsoft.NETCore.App 2.2.0
• WriteOnlyPrivateField (Pluto.API/Controllers/OrderController.cs)
• misleading comment (Pluto.API/Controllers/OrderController.cs)
• misleading comment (Pluto.Domain/Handlers/Commands/ProductCommandHandler.cs)

• Unchanged — 12 HTTP endpoints

• Unchanged — 2 containers · 1 contexts · 0 edges

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

spaki/Pluto was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.