evgenirusev/.NET-Domain-Driven-Design-Template

This system is a modular .NET 10 application structured around bounded contexts (Product Catalog, Order Management, Identity, and Statistics) that run within a single binary to avoid microservice complexity. It provides domain-driven capabilities for managing products, processing orders, handling user authentication, and tracking aggregate statistics, all supported by a shared infrastructure layer for database persistence, event dispatching, and HTTP client integration.

A new HTTP service, ProductCatalogHttpService, has been introduced to handle communication with the product catalog API. This service provides a method to retrieve product details by ID, enabling the order management system to fetch and enrich order data with product information.

OrderManagement/OrderManagement.Infrastructure/HttpServices · high confidence

The Common.Infrastructure project now provides a centralized \InfrastructureConfiguration\ class that registers database storage, JWT-based token authentication, event sourcing, and HTTP client handlers. Users can now register these core infrastructure services via extension methods, including automatic repository scanning and SQL Server connection string retrieval.

Common/Common.Infrastructure · high confidence

Introduces the UpdateOrderCommand and its associated validator in the OrderManagement.Application layer. The command handler retrieves the order via IOrderDomainRepository, validates its existence, updates its status using the OrderStatus enumeration, and persists the change. The validator delegates to OrderCommandValidator to ensure the request payload is valid before processing.

OrderManagement/OrderManagement.Application/Orders/Commands/Update · high confidence

A new ImageService implementation has been added to handle image processing, specifically resizing images to a 100-pixel width for thumbnails. The service uses the SixLabors.ImageSharp library to load images, resize them, strip EXIF metadata, and save as JPEG.

Common/Common.Infrastructure/Services · high confidence

The application layer now includes the complete set of MediatR commands and queries for managing products. This includes CreateProductCommand with its handler and validator, UpdateProductCommand with its handler and validator, DeleteProductCommand with its handler, and ProductDetailsQuery with its handler. The changes introduce ProductModel as a shared DTO, along with corresponding validators that enforce constraints on name, description, price, and weight. Additionally, a new ProductsApplicationConfiguration class registers the application services.

ProductCatalog/ProductCatalog.Application · high confidence

The application now includes the core infrastructure for the statistics feature, introducing a new \StatisticsDbContext\ to manage the \TotalStatistics\ entity and a \StatisticsDbInitializer\ to seed initial data. The \InfrastructureConfiguration\ class registers the database storage and the transient \IDbInitializer\ service, enabling the system to persist and initialize statistics data.

Statistics/Statistics.Infrastructure/Persistence · medium confidence

New EF Core mapping classes (ProductConfiguration and SupplierConfiguration) define the database schema for the ProductCatalog domain. These configurations specify column names, length constraints, precision for monetary and weight values, and the many-to-many relationship between Products and Suppliers via a ProductSupplier join table.

ProductCatalog/ProductCatalog.Infrastructure/Configurations · high confidence

The ProductCatalog.Web project now includes a new ProductsController that exposes HTTP endpoints for retrieving, creating, and updating products, along with a WebConfiguration class that registers the necessary web components and dependencies for the product catalog feature.

ProductCatalog/ProductCatalog.Web · high confidence

The application now includes a new database initialization system. A new \DbInitializer\ class implements \IDbInitializer\ to manage database migrations and populate the database with initial data from registered providers. This allows the application to automatically apply schema changes and seed the database on startup.

Common/Common.Infrastructure/Persistence · high confidence

A new DomainConfiguration class was added to the Identity.Domain project, providing a registration method that configures the common domain services for the identity module.

Identity/Identity.Domain · high confidence

The Identity/Identity.Infrastructure layer now includes the full implementation for user and role management. This introduces the IdentityDbContext, a set of Entity Framework Core migrations (including the initial schema and updates for roles and claims), and the associated services (IdentityService, JwtGeneratorService) that handle registration, login, and password changes. The database schema is updated to support ASP.NET Core Identity tables (Users, Roles, Claims, Logins, etc.) and a default administrator account is seeded on initialization.

Identity/Identity.Infrastructure · high confidence

A new static class, InfrastructureConfiguration, has been introduced in the ProductCatalog.Infrastructure project. This class provides an extension method, AddProductCatalogInfrastructure, which registers the database storage for the ProductDbContext and adds a transient IDbInitializer implementation (ProductDbInitializer) to the service collection, effectively wiring up the database context and initialization logic for the product catalog.

ProductCatalog/ProductCatalog.Infrastructure · high confidence

Users can now retrieve a list of all orders or the details of a specific order. The 'Get All' endpoint enriches each order item with the corresponding product name by calling the product catalog service, while the 'Details' endpoint returns the full order information.

OrderManagement/OrderManagement.Application/Orders/Queries · high confidence

Added the OrderRepository class which implements IOrderDomainRepository and IOrderQueryRepository. It provides data access methods for finding, deleting, and retrieving order details using Entity Framework Core and AutoMapper, including a GetAll method that returns a list of order items with product IDs and quantities.

OrderManagement/OrderManagement.Infrastructure/Repositories · high confidence

Added the initial Entity Framework Core migration for the Product Catalog infrastructure, establishing the database schema for the Product, Supplier, and ProductSupplier entities. This migration creates the Products, Suppliers, and ProductSupplier tables, defining columns for product details (name, description, price, weight, type), supplier information (contact details, address), and the many-to-many relationship between products and suppliers.

ProductCatalog/ProductCatalog.Infrastructure/Migrations · high confidence

The OrderManagement.Web project now exposes a new OrdersController that provides RESTful endpoints for order management, including GetAll, GetById, Create, and Update operations. Additionally, WebConfiguration registers the necessary web components for the order management feature.

OrderManagement/OrderManagement.Web · medium confidence

The OrderManagement domain now includes the core Order, OrderItem, and OrderStatus models, along with an OrderFactory for construction. The Order entity enforces validation rules (e.g., order date cannot be in the future, quantity limits) and manages order items. The OrderStatus enum defines the lifecycle states (Pending, Processing, Shipped, Delivered, Cancelled).

OrderManagement/OrderManagement.Domain/Models · high confidence

Added a new OrderManagementDbContext class that inherits from a base context with event dispatching, exposing DbSets for Order and OrderItem entities, and a corresponding OrderManagementDbInitializer to handle database initialization and seeding.

OrderManagement/OrderManagement.Infrastructure/Persistence · high confidence

A new ProductDbContext class has been added to the persistence layer, exposing DbSets for Supplier and Product entities and configuring model mappings from the executing assembly. Additionally, a ProductDbInitializer has been introduced to handle database initialization with sample ProductData.

ProductCatalog/ProductCatalog.Infrastructure/Persistence · high confidence

Added foundational domain model components to the Common.Domain layer, including an abstract Entity base class with GUID-based identity and domain event tracking, an Enumeration base class for strongly-typed enumerations with caching, and a ValueObject base class for value-type equality and comparison. Additionally, a Guard class was introduced to provide static validation methods for string length, range, and emptiness checks, alongside a Message class for serializing and deserializing domain events.

Common/Common.Domain/Models · high confidence

Added new domain entities and repository interfaces to support tracking aggregate statistics, specifically the total number of orders and products created. This includes a \TotalStatistics\ entity with methods to increment order and product counts, a corresponding data initializer, and a repository interface defining methods to increment these counts.

Statistics/Statistics.Domain · high confidence

Added the IEventDispatcher interface and its EventDispatcher implementation in the Common.Infrastructure.Events namespace. The dispatcher uses service collection resolution to find all registered IEventHandler implementations and invokes them for each domain event, enabling asynchronous event handling across the application.

Common/Common.Infrastructure/Events · high confidence

The application now supports user registration, login, and password change operations. The Identity layer exposes an IIdentity interface with methods for Register, Login, and ChangePassword. The Identity.Web layer exposes corresponding HTTP endpoints (POST for register and login, PUT for password change) that route to MediatR commands. Validation rules enforce email format, password length, and confirmation matching for registration, and require the current password for password changes.

Identity/Identity.Application · high confidence

The application now includes a new command handler for creating orders, which constructs an order using an order factory and saves it via a domain repository. The command accepts order details and items, while the response returns the generated GUID-based order ID.

OrderManagement/OrderManagement.Application/Orders/Commands/Create · high confidence

The new ProjectStartup project establishes the application's entry point, registering domain, application, and infrastructure services for Product Catalog, Order Management, Statistics, and Identity, alongside token authentication, event sourcing, and Swagger. It configures a custom middleware pipeline that handles exception handling, HTTPS redirection, routing, CORS, authentication, and authorization, and initializes database contexts via IDbInitializer.

ProjectStartup · high confidence

Added OrderModel and OrderItemModel classes to the application layer to represent order data. OrderModel includes properties for customer ID, order date, status, and a list of order items, with a mapping configuration to handle the status value conversion. OrderItemModel defines the structure for individual items within an order, specifying product ID and quantity.

OrderManagement/OrderManagement.Application/Orders/Common · high confidence

The application now includes a new HTTP service interface, IProductCatalogHttpService, which allows the system to retrieve product details by ID. This is supported by a new ProductResponse model containing Id and Name fields, enabling the order management flow to fetch product information from the external catalog.

OrderManagement/OrderManagement.Application/Services · medium confidence

The Common.Web project now provides a reusable foundation for ASP.NET Core APIs. It includes an abstract ApiController base class that simplifies MediatR command/query execution and result mapping. New exception handlers standardize error responses for domain, not-found, and validation issues. A CurrentUserService resolves the authenticated user's identity, and an ImageModelBinder with its provider enables seamless file upload handling. These components are wired up via WebConfiguration extension methods, streamlining the setup of validation, exception handling, and model binding across web services.

Common/Common.Web · high confidence

A new IOrderDomainRepository interface is introduced, defining the contract for order repository operations. It extends IDomainRepository and specifies methods to find an Order by its GUID identifier and to delete an Order by its GUID. This change establishes the repository pattern for order management, utilizing GUIDs for identification.

OrderManagement/OrderManagement.Domain/Repositories · high confidence

The ProductCatalog.Domain project now includes the core domain models for products and suppliers, including the Product, Supplier, Price, Weight, and Address classes, along with their respective model constants for validation. A ProductFactory is added to construct Product instances, and an IProductDomainRepository interface is introduced to define data access operations for products. This change establishes the foundational structure for managing product and supplier data within the domain layer.

ProductCatalog/ProductCatalog.Domain · high confidence

A new abstract base class, DataRepository, has been added to the Common infrastructure layer. This class provides a generic implementation for database interactions, including methods to retrieve all entities (with and without tracking) and a Save method that handles both adding new entities and updating existing ones based on their ID state. This change establishes a standardized pattern for repository implementations within the application.

Common/Common.Infrastructure/Repositories · high confidence

The Common.Application project now includes a centralized ApplicationConfiguration for registering MediatR, AutoMapper, and event handlers, alongside a RequestValidationBehavior that enforces FluentValidation on all MediatR requests. A generic Result type is added for command and query operations, and a base EntityCommand class provides a shared Id property. The change also introduces interfaces for current user and image processing, along with mapping profiles and application settings.

Common/Common.Application · high confidence

The Common.Domain layer now provides core abstractions for domain-driven design, including a generic Specification pattern for building and composing query filters, along with interfaces for aggregate roots, repositories, and factories. These are wired into the application's service collection via a new DomainConfiguration class that automatically registers factory and initial data implementations, enabling a more structured approach to data access and object creation within the domain model.

Common/Common.Domain · medium confidence

The application now supports domain-driven design through a new eventing system. A base interface, IDomainEvent, has been added to the Common domain layer. Additionally, specific event classes, OrderAddedEvent and ProductAddedEvent, have been introduced to capture when new orders or products are added to the system.

Common/Common.Domain/Events · high confidence

The solution has been restructured to support a vertical slice architecture where each bounded context (ProductCatalog, OrderManagement, Statistics, Identity) is isolated in its own set of projects (Domain, Application, Infrastructure, Web). This change enforces strict separation between domains to minimize coupling, while all contexts run within a single binary to avoid microservice complexity. The template now includes a run\_migrations.sh script to initialize multiple databases (Statistics, Product, Order, Identity) and provides a diagram illustrating the layered architecture (Web, Infrastructure, Application, Domain) for each context.

(repo-wide) · high confidence

A new settings class, OrderManagementSettings, is introduced to hold configuration for the ProductCatalogAPIClient, specifically its BaseUrl. A corresponding extension method, GetOrderManagementSettings, is added to the infrastructure layer to bind the 'OrderManagementSettings' section of the application configuration into this model, enabling the application to read external API client configuration from the configuration source.

OrderManagement/OrderManagement.Application/Settings, OrderManagement/OrderManagement.Infrastructure/Extensions · high confidence

A new EF Core configuration class (MessageConfiguration) has been added to define how the Message entity is persisted. This includes setting the primary key, marking the serializedData field as required, and configuring the Type property to store and retrieve assembly-qualified type names. The Data property is explicitly ignored in the database mapping.

Common/Common.Infrastructure/Configuration · medium confidence

The Statistics module now includes its first database migration, creating a 'TotalStatistics' table with columns for 'TotalOrdersCreated' and 'TotalProductsCreated' using GUID primary keys. This establishes the initial schema for tracking aggregate statistics in the database.

Statistics/Statistics.Infrastructure/Migrations · high confidence

The system now tracks aggregate statistics for orders and products. A new \StatisticsRepository\ was added to handle incrementing total orders and products, and a \TotalStatisticsConfiguration\ was introduced to map the \TotalStatistics\ entity to the database.

Statistics/Statistics.Infrastructure/Repositories · high confidence

New configuration classes (OrderConfiguration and OrderItemConfiguration) have been added to define the mapping and relationships for the Order and OrderItem entities. These configurations specify primary keys, required properties, and the one-to-many relationship between orders and their items, ensuring the database schema aligns with the domain model.

OrderManagement/OrderManagement.Infrastructure/Configurations · high confidence

The system now enforces that an order contains between the minimum and maximum allowed number of items, and that each item's quantity falls within the defined minimum and maximum bounds. These constraints are implemented via new validators for the OrderCommand, ensuring that orders with zero items or quantities outside the allowed range are rejected with specific error messages.

OrderManagement/OrderManagement.Application/Orders/Commands/Common · medium confidence

The OrderManagement module now exposes dedicated static methods—AddOrderManagementApplication and AddOrderManagementDomain—to register common application and domain services. This change consolidates the service registration logic, making it easier to wire up the application and domain layers in a single call.

OrderManagement/OrderManagement.Application · medium confidence

The OrderManagement infrastructure layer now provides a unified entry point for setting up database storage, database initialization, and HTTP client services. Users can register all infrastructure dependencies via a single \AddOrderManagementInfrastructure\ method, which configures the \OrderManagementDbContext\, the \OrderManagementDbInitializer\, and typed HTTP clients for the product catalog API.

OrderManagement/OrderManagement.Infrastructure · medium confidence

Added the ProductRepository class which implements IProductDomainRepository and IProductQueryRepository. It provides methods to find a product by its GUID ID, retrieve product details using AutoMapper, and delete products, ensuring that all operations are performed using GUID identifiers rather than other ID types.

ProductCatalog/ProductCatalog.Infrastructure/Repositories · medium confidence

The system now includes the initial database migration to create the 'Orders' and 'OrderItems' tables. This migration establishes the schema for managing orders, including customer and product references, order dates, and associated line items with their quantities.

OrderManagement/OrderManagement.Infrastructure/Migrations · high confidence

The application now automatically updates statistics when orders or products are added. New event handlers in the application layer listen for OrderAddedEvent and ProductAddedEvent, incrementing the respective counters via the statistics repository. A new query repository interface exposes the total statistics, and the web layer exposes a StatisticsController to serve this data.

Statistics/Statistics.Application · medium confidence

A new abstract base class, BaseDbContext, is added to the infrastructure layer. This class overrides SaveChangesAsync to automatically detect and dispatch domain events associated with changed entities, ensuring that business logic tied to state changes is executed consistently. It includes a reentrancy guard (\_isDispatching) to prevent infinite loops when event handlers trigger further saves.

Common/Common.Infrastructure/DBContext · high confidence

Added new unit tests for the ProductCommandValidator, covering validation scenarios such as rejecting empty names, rejecting zero prices, and accepting valid commands.

tests · high confidence

The solution has been upgraded to target .NET 10 LTS, updating all project files to use the \net10.0\ target framework. This change introduces a centralized package version management via \Directory.Packages.props\, which defines specific versions for key libraries including MediatR 14.1.0, FluentValidation 11.12.0, AutoMapper 16.1.1, and Microsoft.AspNetCore.Identity 10.0.8. The project structure has been reorganized into distinct layers (Application, Domain, Infrastructure, Web) for Identity, OrderManagement, ProductCatalog, and Statistics modules, each referencing the shared Common layer.

(dependencies) · high confidence

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

• CAI 61 → 59 (-1.9)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 85 → 70 (-14.6)
• Architecture 88 → 88 (+0.0)
• Maturity 63 → 63 (+0.2)
• Readiness 75 → 76 (+1.2)
• Security 78 → 73 (-5.0)
• Domain Modelling 49 → 48 (-1.2)
• Event-Driven 100 → 100 (+0.0)

• Bounded contexts not declared
• High: security finding (details withheld)
• High: security finding (details withheld)
• Inconsistent naming for CQRS commands. Some commands are named with the action verb (Create, Update, Delete) while others are named with the entity and action (ChangePassword, RegisterUser). This creates a mix of 'Verb+Entity' and 'Entity+Verb' patterns.
• Inconsistent naming for DTO/ViewModel types. Some use the 'Model' suffix (e.g., OrderModel, ProductModel), while others use 'ListItem', 'Response', or 'Request' suffixes. This makes it unclear if 'Model' refers to a database entity, a view model, or a DTO.
• Inconsistent repository interface naming convention. Some repositories use the 'Domain' suffix (e.g., IOrderDomainRepository) while others use 'Query' or 'Domain' without a clear pattern (e.g., IOrderQueryRepository, IProductDomainRepository). The naming does not consistently distinguish between domain-specific operations and query-specific operations across all entities.
• No exposed public API
• Small-team knowledge concentration

• Documentation: no architecture or design documentation (README.md)
• Documentation: no installation or build instructions (README.md)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Inconsistent method naming for retrieving an entity by ID: Query repositories use 'GetDetailsById' while Domain repositories use 'Find'. This creates two different verbs for the same conceptual operation (retrieving a single entity by its identifier) across different repository interfaces.
• Inconsistent repository naming convention: Product repository uses 'Domain' in interface name (IProductDomainRepository) while Order repository uses 'Domain' in interface name (IOrderDomainRepository), but other repositories in the same codebase use 'Query' or 'Repository' (e.g., IProductQueryRepository, IOrderQueryRepository, StatisticsRepository). While both use 'Domain', the existence of separate Query/Domain interfaces for the same aggregates suggests a split that should be consistently named across all aggregates (e.g., all using IProductRepository/IOrderRepository or all using IProductDomainRepository/IOrderDomainRepository). However, since both Product and Order use 'Domain' here, they are consistent with each other. The inconsistency is actually between the types of repositories used for Product vs Order. Product has IProductDomainRepository AND IProductQueryRepository. Order has IOrderDomainRepository AND IOrderQueryRepository. This is consistent. Let's look closer. Is there a mismatch? No. Product has Domain and Query. Order has Domain and Query. This is consistent.
• No dependency advisory monitoring
• Outdated: xunit.runner.visualstudio
• Workflow token permissions not restricted
• WriteOnlyPrivateField (Statistics/Statistics.Infrastructure/Repositories/StatisticsRepository.cs)
• redundant comment (OrderManagement/OrderManagement.Domain/Models/Orders/ModelConstants.cs)

• Unchanged — 3 HTTP endpoints

• Unchanged — 2 containers · 4 contexts · 3 edges

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

evgenirusev/.NET-Domain-Driven-Design-Template 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.