AntonioFalcaoJr/EventualShop

This system is a .NET 8 microservices platform implementing Clean Architecture, CQRS, and Event Sourcing to manage core e-commerce domains including identity, catalog, orders, payments, and inventory. It utilizes SQL Server for event persistence and MongoDB for read-side projections, communicating asynchronously via RabbitMQ and exposing gRPC interfaces for service interaction. The architecture enforces strict data integrity through FluentValidation and provides robust infrastructure for message routing, logging, and transactional consistency across bounded contexts.

144 changes.

The project was initialized with a .NET 8 clean architecture, establishing a multi-service structure for domains like Identity, Order, and Account. This period focused on implementing the core infrastructure for event sourcing, including Event Store persistence, MassTransit message bus integration, and gRPC contract definitions across all bounded contexts.

81 changes.

This period focused on migrating multiple command services to a new event-sourcing architecture, introducing standardized AggregateRoot, EventStore, and Interactor patterns across the codebase. Concurrently, query services were refactored to use event-driven projections backed by MongoDB, ensuring read models stay consistent with domain events. The work also included establishing unified infrastructure for message buses, validation, and gRPC query endpoints.

A new Gender enumeration has been introduced in the Contracts layer, providing standardized values for Male, Female, NonBinary, and Undefined. This type uses the Ardalis.SmartEnum library and supports implicit conversions to and from strings and integers, allowing for easier integration with data models and APIs that require gender classification.

src/Contracts/Enumerations · high confidence

New converters have been added to the Contracts.JsonConverters namespace to handle the \DateOnly\ type across multiple serialization libraries. This includes \DateOnlyJsonConverter\ and \ExpirationDateOnlyJsonConverter\ for Newtonsoft.Json (using formats \dd/MM/yyyy\ and \MM/yy\ respectively), \DateOnlyTextJsonConverter\ for System.Text.Json (using \yyyy-MM-dd\), and \ExpirationDateOnlyBsonSerializer\ for MongoDB Bson (using \MM/yy\). Additionally, a \TypeNameHandlingConverter\ was introduced to manage type name handling in Newtonsoft.Json while excluding MassTransit and system types.

src/Contracts/JsonConverters · high confidence

This change introduces the core components for JWT-based authentication within the Identity service. It adds a \JwtTokenGenerator\ that creates signed tokens containing user claims (ID, name, email) using HMAC-SHA256, configured via a new \JwtOptions\ record that enforces required fields for the secret key, issuer, audience, and expiry minutes. These components are wired together through a new \ServiceCollectionExtensions\ class, which registers the token generator as a scoped service and configures the options with data annotation validation. An empty \PasswordHasher\ class is also added to the infrastructure layer, likely as a placeholder for future password handling logic.

src/Services/Identity/Query/Infrastructure.Authentication · high confidence

New domain entities for OrderItem and PaymentMethod have been introduced in the Order Command service. OrderItem now models individual line items with a product and quantity, while PaymentMethod captures payment details including amount and specific option types (CreditCard, DebitCard, PayPal). Both entities include implicit conversion operators to and from their corresponding Data Transfer Objects (DTOs) to facilitate data mapping, along with associated FluentValidation validators.

src/Services/Order/Command/Domain/Entities · high confidence

A new strongly-typed resource class (EmailResource) and its corresponding .resx file have been added to the Application layer, introducing a localized HTML template for the email confirmation message. This template includes a greeting, a call to action to confirm the email address via a form submission, and placeholders for the recipient's name and confirmation link, enabling the system to send structured, localized confirmation emails to new users.

src/Services/Communication/Command/Application/Resources · high confidence

A new interactor has been introduced to handle the CartItemAdded domain event by automatically reserving the corresponding inventory. When a user adds an item to their cart, this logic loads the relevant inventory aggregate and issues a ReserveInventoryItem command to secure the stock, ensuring inventory is reserved at the point of cart addition.

src/Services/Warehouse/Command/Application/UseCases/Events · high confidence

The EventBus layer now includes \LoggingConsumeObserver\ and \LoggingReceiveObserver\ classes that implement MassTransit's \IConsumeObserver\ and \IReceiveObserver\ interfaces. These observers automatically log detailed information about message consumption and reception, including message types, namespaces, correlation IDs, exchange names, processing durations, and any faults or errors encountered, providing enhanced visibility into the event bus's runtime behavior.

src/Services/Communication/Query/Infrastructure.EventBus/PipeObservers · high confidence

New consumer classes have been added to the Identity Command service's message bus infrastructure to handle specific domain and delayed events. These include consumers for account deactivation and deletion, user registration, email confirmation and changes, and email confirmation expiration. Each consumer acts as a bridge, receiving the corresponding event (such as DomainEvent.AccountDeactivated or DelayedEvent.EmailConfirmationExpired) and delegating processing to the application layer via an interactor.

src/Services/Identity/Command/Infrastructure.MessageBus/Consumers/Events · high confidence

The Order Command service now includes two new MassTransit pipe filters to handle validation failures. The ContractValidatorFilter intercepts incoming messages, validates them against FluentValidation rules, and routes validation errors to a dedicated contract-errors queue. The BusinessValidatorFilter catches ValidationExceptions during message processing and routes business validation errors to a separate business-error queue, ensuring that validation issues are logged and handled asynchronously without blocking the main message flow.

src/Services/Account/Command/Infrastructure.MessageBus/PipeFilters, src/Services/Order/Command/Infrastructure.MessageBus/PipeFilters · high confidence

The Account and Identity query services now include \LoggingConsumeObserver\ and \LoggingReceiveObserver\ components within their \Infrastructure.EventBus\ layers. These observers integrate with MassTransit to automatically log message consumption and reception events using Serilog, providing visibility into message flow, correlation IDs, and processing faults for both services.

src/Services/Account/Query/Infrastructure.EventBus/PipeObservers, src/Services/Identity/Query/Infrastructure.EventBus/PipeObservers · high confidence

The system now includes dedicated logging observers for the MassTransit message bus infrastructure. These new components automatically log key lifecycle events for messages, including publishing, sending, receiving, and consuming. Users will see structured logs capturing message types, namespaces, correlation IDs, exchange details, and operation durations, as well as error details for any faults that occur during these processes, enhancing observability of message flow.

src/Services/Communication/Command/Infrastructure.MessageBus/PipeObservers · high confidence

The Order Command service now includes structured logging for all message bus activities via new MassTransit observers. LoggingConsumeObserver, LoggingPublishObserver, LoggingReceiveObserver, and LoggingSendObserver have been added to track message consumption, publishing, receiving, and sending. These observers log key details such as message type, namespace, correlation ID, exchange information, and any faults or errors using Serilog, providing better visibility into message flow and troubleshooting capabilities for the Order Command stack.

src/Services/Order/Command/Infrastructure.MessageBus/PipeObservers · high confidence

New pipe filters have been introduced in the Identity Command service's message bus infrastructure to handle validation errors gracefully. The \ContractValidatorFilter\ intercepts incoming messages to validate their structure using FluentValidation, routing any contract violations to a dedicated error queue. Additionally, the \BusinessValidatorFilter\ catches \ValidationException\s thrown during message processing and forwards them to a separate business-error queue, ensuring that validation failures are logged and isolated from standard message flows.

src/Services/Identity/Command/Infrastructure.MessageBus/PipeFilters · high confidence

The shopping cart service now includes two new pipe filters for its message bus infrastructure: a contract validator that checks incoming command messages against FluentValidation rules and routes validation failures to a dedicated error queue, and a business validator that catches validation exceptions during processing and sends them to a separate business error queue. This change introduces structured error handling for both schema/contract issues and business logic violations, ensuring that invalid messages are logged and routed appropriately rather than failing silently or crashing the consumer.

src/Services/ShoppingCart/Command/Infrastructure.MessageBus/PipeFilters · high confidence

The communication service now includes two new pipe filters to validate incoming messages before processing. The ContractValidatorFilter checks messages against defined FluentValidation rules and routes validation failures to a dedicated contract-errors queue. The BusinessValidatorFilter catches ValidationExceptions during processing and routes them to a business-error queue, ensuring that both structural and business-logic validation issues are handled consistently and logged via Serilog.

src/Services/Communication/Command/Infrastructure.MessageBus/PipeFilters · high confidence

A new interactor for retrieving payment details has been added to the payment query service. This component implements the interaction logic for the GetPaymentDetails query, delegating the data retrieval to a projection gateway to fetch the corresponding PaymentDetails projection.

src/Services/Payment/Query/Application/UseCases/Queries · high confidence

The Identity Command service now includes dedicated observers for the MassTransit message bus that log key lifecycle events. These new components track publishing, sending, receiving, and consuming of messages, recording details such as message type, namespace, correlation ID, exchange name, and processing duration. This provides better visibility into message flow and helps diagnose issues by logging faults and performance metrics directly from the infrastructure layer.

src/Services/Identity/Command/Infrastructure.MessageBus/PipeObservers · high confidence

A new interactor for retrieving user details has been added to the query application layer. This component validates the provided email and password against stored projection data and, upon successful authentication, generates and returns a JWT token for the user.

src/Services/Identity/Query/Application/UseCases/Queries · high confidence

This change introduces a new set of FluentValidation validators for the application's data transfer objects, ensuring data integrity before processing. Specifically, it adds validation for Address (requiring city, country, state, street, and zip code, with conditional rules for number and complement), CreditCard and DebitCard (validating expiration, number format, holder name, and security code), Money (ensuring positive amount and non-empty currency), PayPal (validating email and password), Product (checking brand, category, description, name, unit, and SKU), Profile (enforcing email format, name lengths, age restrictions, and gender enumeration), and ShoppingCartItem (validating quantity). These validators are now part of the Contracts layer to standardize input validation across the system.

src/Contracts/DataTransferObjects/Validators · high confidence

The Catalog Command service now includes four new MassTransit pipe observers (LoggingConsumeObserver, LoggingPublishObserver, LoggingReceiveObserver, LoggingSendObserver) that automatically log message lifecycle events. Users will see informational logs for message consumption and publishing, debug logs for receive and send details (including exchange names and durations), and error logs for any faults during these operations, all correlated by CorrelationId.

src/Services/Catalog/Command/Infrastructure.MessageBus/PipeObservers · high confidence

The Account service now includes structured logging for all message bus activities. New observer classes (LoggingConsumeObserver, LoggingPublishObserver, LoggingReceiveObserver, and LoggingSendObserver) have been added to the Infrastructure.MessageBus.PipeObservers namespace. These observers log information, debug, and error details for publishing, sending, receiving, and consuming messages, including correlation IDs, message types, namespaces, and fault exceptions, leveraging Serilog and MassTransit interfaces.

src/Services/Account/Command/Infrastructure.MessageBus/PipeObservers, src/Services/ShoppingCart/Command/Infrastructure.MessageBus/PipeObservers, src/Services/Warehouse/Command/Infrastructure.MessageBus/PipeObservers · high confidence

The SMTP infrastructure now provides a dedicated dependency injection extension to register the email notification gateway and configure the SMTP client. Users can now bind SMTP settings (host, port, credentials, SSL) via configuration options and register the INotificationGateway\<Email\> implementation, enabling the system to send emails through the specified SMTP server.

src/Services/Communication/Command/Infrastructure.SMTP/DependencyInjection/Extensions · high confidence

The Event Store infrastructure now supports aggregate snapshots and includes timestamps for both stored events and snapshots. This is implemented via new EF Core configurations for the Snapshot and StoreEvent entities, which enforce required fields for version, aggregate ID, type, and timestamp, and utilize custom value converters to serialize aggregate roots and domain events to JSON. The EventStoreDbContext exposes these as DbSets and applies the new configurations automatically.

src/Services/Communication/Command/Infrastructure.EventStore/Contexts · high confidence

The Account service's command infrastructure now includes a new dependency injection extension that registers the Event Store gateway, repository, and database context. This change wires up the EventStoreDbContext with SQL Server, enabling configurable retry strategies and detailed error logging, and exposes configuration options for SQL Server retries and general Event Store settings.

src/Services/Account/Command/Infrastructure.EventStore/DependencyInjection/Extensions · high confidence

The Communication Command service now registers its Event Store infrastructure components through a new \ServiceCollectionExtensions\ class. This includes registering the \EventStoreGateway\, \EventStoreRepository\, and \UnitOfWork\ as scoped services, along with configuring a pooled \EventStoreDbContext\ connected to SQL Server. The database connection uses configurable retry strategies for transient failures and enables detailed error logging and sensitive data logging for debugging purposes.

src/Services/Communication/Command/Infrastructure.EventStore/DependencyInjection/Extensions · high confidence

The Account service's command infrastructure now persists domain events and snapshots to a SQL Server database using Entity Framework Core. This includes new \EventStoreDbContext\ configurations for \StoreEvent\ and \Snapshot\ entities, which store event data as JSON with specific converters for aggregate roots and domain events, and enforce a \Timestamp\ field. Additionally, the system initializes a dedicated 'Quartz' database and creates the necessary tables to support the Quartz.NET job scheduling library.

src/Services/Account/Command/Infrastructure.EventStore/Contexts · high confidence

The Order Command service now includes Entity Framework Core configuration for persisting domain snapshots and events. This adds an \EventStoreDbContext\ with \StoreEvent\ and \Snapshot\ entity sets, along with specific mappings that enforce required fields (Version, AggregateId, AggregateType, Timestamp) and apply JSON serialization converters to store aggregate roots and domain events as strings. The configuration also sets global conventions for string properties to be non-Unicode with a maximum length of 1024 characters.

src/Services/Order/Command/Infrastructure.EventStore/Contexts · high confidence

The Account Query service now integrates with the event bus via MassTransit and RabbitMQ, enabling it to react to account lifecycle events. The DI configuration registers consumers for events such as AccountCreated, AccountActivated, AccountDeleted, and address changes, routing them to specific Interactors/Consumers. Queue names are generated using a kebab-case naming convention, and the connection uses a configurable name and connection string. The setup includes incremental retry policies, Newtonsoft.Json serialization with custom converters for DateOnly and expiration dates, contract validation filters, and logging observers for receive and consume operations.

src/Services/Account/Query/Infrastructure.EventBus/DependencyInjection · high confidence

The Communication Query service now includes an event bus infrastructure layer built on MassTransit and RabbitMQ. This change introduces dependency injection extensions to configure the bus, including connection settings, retry policies, and JSON serialization. It also adds a base consumer class for handling events and specific endpoint configurations for domain events like 'NotificationRequested', enabling the service to receive and process messages from the event stream.

src/Services/Communication/Query/Infrastructure.EventBus/DependencyInjection · high confidence

The Order Command service now includes database migrations that establish the underlying storage for its event sourcing infrastructure and background job scheduling. The first migration creates the 'Events' and 'Snapshots' tables to persist domain events and aggregate snapshots, including versioning, aggregate identifiers, and timestamps. A subsequent migration provisions a dedicated 'Quartz' database and its required schema (including tables for triggers, jobs, and scheduler state) to support the Quartz.NET job scheduler.

(repo-wide) · high confidence

The Communication service's Event Store now includes the foundational database schema for persisting domain events and snapshots, introducing 'Events' and 'Snapshots' tables that store aggregate identifiers, versions, types, payloads, and timestamps. Additionally, a migration has been added to provision the Quartz database and its required tables (such as triggers, jobs, and calendars), enabling the service to utilize the Quartz scheduler for background job execution.

src/Services/Communication/Command/Infrastructure.EventStore/Migrations · high confidence

This change introduces the foundational infrastructure for the Account Command Worker Service, including a Dockerfile targeting .NET 8.0-preview, a .dockerignore file, and environment-specific configuration files (Development, Staging, Production). The service is configured to connect to SQL Server for the EventStore and Quartz scheduling, and uses RabbitMQ via MassTransit for the message bus. The Program.cs sets up dependency injection for application services, event store contexts, and message bus options, with database migrations applied automatically in Development and Staging environments.

src/Services/Account/Command/WorkerService · high confidence

The repository is initialized with a comprehensive solution structure implementing Clean Architecture, CQRS, and Event Sourcing patterns across multiple bounded contexts (Account, Identity, Catalog, Order, etc.). The build system is configured for .NET 8.0 (preview) with nullable reference types and implicit usings enabled via Directory.Build.props. Key dependencies include MassTransit 8.0.14 for event bus communication, MongoDB 2.19.0 for projections, and gRPC 2.52.0 for service communication. Development and staging environments are supported via Docker Compose files defining infrastructure services like MSSQL, RabbitMQ, MongoDB, Jaeger, and ELK stack.

(repo-wide) · high confidence

The ShoppingCart Command Worker Service is now available as a standalone .NET 8 application, enabling the system to process shopping cart commands via a background worker. This service integrates with an Event Store for persistence, uses MassTransit for message bus communication, and Quartz for scheduled job execution. It is containerized via a new Dockerfile and configured for local, staging, and production environments, providing the foundational infrastructure for handling shopping cart command operations.

(repo-wide) · high confidence

This change introduces the new Warehouse Query gRPC service, providing endpoints to list inventory items and inventory grid items. The service is built on .NET 8 and exposes a gRPC API that delegates to paged interactors for data retrieval. It is configured to connect to MongoDB for projections and RabbitMQ for the event bus, with specific connection strings defined for development (localhost) and production/staging (container hostnames). The service uses Serilog for logging, MassTransit for event handling, and enforces HTTP/2 protocol via Kestrel.

src/Services/Warehouse/Query/GrpcService · high confidence

This change introduces the Identity Command Worker Service, a new .NET 8 background worker responsible for handling identity-related command operations. The service is configured with a Dockerfile targeting .NET 8.0-preview and includes infrastructure for an Event Store (using SQL Server), a Message Bus (using MassTransit with RabbitMQ), and Quartz scheduling. It registers DI services for application logic, event interactors, and message validators, and supports configuration via JSON settings files for Development, Staging, and Production environments.

src/Services/Identity/Command/WorkerService · high confidence

The Order Command Worker Service is now available as a standalone .NET 8 application, containerized via a new Dockerfile and .dockerignore. It bootstraps a hosted service that registers dependency injection for the Order Command and Query stacks, including Event Store, Message Bus (MassTransit), and Quartz scheduling. The service is configured with connection names, retry policies, and Serilog logging, and supports environment-specific settings for local (127.0.0.1), staging, and production deployments.

src/Services/Order/Command/WorkerService · high confidence

The Order Command service now includes an EventBusGateway implementation that wraps MassTransit's IBus and IPublishEndpoint to handle event publishing. This component enables the application to publish single or multiple events asynchronously and supports scheduling delayed events, providing the underlying infrastructure for the service's communication layer.

src/Services/Order/Command/Infrastructure.MessageBus · high confidence

Defines the interface contracts for the Order service, including command records (PlaceOrder, ConfirmOrder, CancelOrder) and query records (GetOrderDetails, ListOrdersGridItems) that map to gRPC requests. It also specifies domain events (OrderPlaced, OrderConfirmed) with versioning, projection models for order details and grid items, and a Protobuf service definition exposing RPCs for retrieving order details and listing orders.

src/Contracts/Services/Order · high confidence

The Order Command service now includes foundational abstractions to standardize domain entities and message handling. Domain entities inherit from a generic base class that enforces validation via a specified FluentValidation validator before operations, ensuring data integrity at the entity level. Additionally, a generic message consumer base class is provided for the MassTransit infrastructure, which automatically routes incoming messages to a corresponding interactor service, simplifying the implementation of new message handlers within the command stack.

src/Services/Order/Command/Domain/Abstractions/Entities, src/Services/Order/Command/Infrastructure.MessageBus/Abstractions · high confidence

The Order Command stack now includes domain value objects for three payment methods: CreditCard, DebitCard, and PayPal. Each model implements the IPaymentOption interface and provides implicit conversions to and from corresponding Data Transfer Objects (DTOs). FluentValidation rules are added for each type to enforce data integrity, such as validating card numbers, expiration dates, holder names, security codes, and email formats.

src/Services/Order/Command/Domain/ValueObjects/PaymentOptions · high confidence

The Order command domain now defines a dedicated event persistence layer through the new IEventStoreRepository interface, which provides methods to append events and snapshots, retrieve streams, and enumerate aggregate IDs. This is supported by new domain models: StoreEvent, which wraps an IDomainEvent with aggregate metadata and versioning, and Snapshot, which captures the current state of an aggregate root at a specific version. These abstractions establish the contract for how the Order service will persist and reconstruct its domain state.

src/Services/Order/Command/Domain/Abstractions/EventStore · high confidence

A new ApplicationService and its corresponding IApplicationService interface have been added to the Order Command Application layer. This service centralizes core event sourcing capabilities, including loading and appending aggregate events via an event store, publishing events through an event bus, and managing unit of work transactions. It provides a unified API for command handlers to interact with the underlying infrastructure for persistence and messaging.

src/Services/Communication/Command/Application/Services, src/Services/Identity/Command/Application/Services, src/Services/Order/Command/Application/Services · high confidence

A new CatalogItem domain entity has been added to the Catalog service, representing an item with properties for inventory ID, product details, unit price, SKU, and quantity. The entity includes methods to increase or decrease stock levels and automatically generates an image URI based on the SKU. A corresponding validator ensures that the quantity remains greater than zero.

src/Services/Catalog/Command/Domain/Entities · high confidence

The system now includes a dedicated Email value object within the Identity service's domain layer, replacing the use of plain strings for email addresses. This new type encapsulates both the email address and its verification status (defaulting to 'Unverified'), and is automatically validated to ensure the address is not empty and follows a valid email format before being used in identity commands.

src/Services/Identity/Command/Domain/ValueObjects · high confidence

A new EventBusGateway implementation has been added to the Communication service's message bus infrastructure. This component acts as the concrete adapter for the IEventBusGateway interface, utilizing MassTransit to handle event publishing and scheduled delayed event publishing, thereby centralizing the interaction with the underlying message broker.

src/Services/Communication/Command/Infrastructure.MessageBus, src/Services/Identity/Command/Infrastructure.MessageBus · high confidence

The application layer now exposes two new interfaces to standardize command handling and transaction management. The IInteractor interface defines a generic contract for processing message-based commands, while the IUnitOfWork interface provides a mechanism to wrap operations within a transactional scope. These abstractions allow implementers to decouple business logic from infrastructure concerns regarding message dispatch and database transaction boundaries.

src/Services/Identity/Command/Application/Abstractions · high confidence

A new MessageBusOptions record has been added to define the configuration requirements for the message bus infrastructure. This record enforces mandatory settings for connection details (ConnectionName and ConnectionString), retry policies (RetryLimit, InitialInterval, IntervalIncrement), and the scheduler queue name (SchedulerQueueName), ensuring these values are provided and validated at the dependency injection level.

src/Services/Order/Command/Infrastructure.MessageBus/DependencyInjection/Options · high confidence

The Communication service now includes a new Notification aggregate root and its corresponding validator. This change introduces the core domain model for managing notification requests and method states (sent, failed, cancelled, reset) within the command side, establishing the foundation for processing these specific communication commands.

src/Services/Communication/Command/Domain/Aggregates · high confidence

The Order Command stack now includes a dedicated OrderStatus enumeration to manage order lifecycle states. This new enum defines specific statuses including Empty, Confirmed, PendingPayment, Failed, Processing, Completed, OnHold, Canceled, and Refunded. It leverages the Ardalis.SmartEnum library and provides implicit conversions between the enum values and their underlying string names and integer values, enabling seamless integration with existing code that expects string or int representations of order status.

src/Services/Order/Command/Domain/Enumerations · high confidence

The Order Command stack now includes a Product value object that encapsulates product details (Description, Name, Brand, Category, Unit, Sku) and provides implicit conversion operators to and from the Dto.Product type, allowing seamless interoperability between domain models and data transfer objects. A corresponding empty validator (ProductValidator) has also been added to the FluentValidation pipeline for this value object.

src/Services/Order/Command/Domain/ValueObjects/Products · high confidence

A new \Infrastructure.Projections\ layer has been added to the Query service, introducing a \ProjectionDbContext\ and a generic \ProjectionGateway\<TProjection\>\ to manage read-side data. This gateway provides capabilities for retrieving, listing (with pagination), deleting, and updating projections stored in MongoDB. It implements optimistic concurrency control via version checks during updates and replace operations, and includes idempotency handling by catching duplicate key exceptions during upserts to ensure safe re-processing of events.

src/Services/Communication/Query/Infrastructure.Projections · high confidence

A new Dto.cs file has been added to the Contracts/DataTransferObjects layer, defining a suite of data transfer objects (DTOs) for core domain concepts including Money, Address, Payment methods (CreditCard, DebitCard, PayPal), Notifications (Email, SMS, Push), Product, Inventory, Catalog, Cart, Order, and Profile. These records include implicit conversion operators to their corresponding Protobuf message types, enabling seamless serialization and communication with external services or gRPC interfaces.

src/Contracts/DataTransferObjects · high confidence

A new abstract base class, Consumer\<TMessage\>, has been added to the message bus abstractions layer. This class implements the MassTransit IConsumer interface and delegates message processing to an injected IInteractor service, providing a standardized pattern for handling incoming messages within the communication infrastructure.

src/Services/Communication/Command/Infrastructure.MessageBus/Abstractions · high confidence

A new abstract base class, Consumer\<TMessage\>, has been added to the message bus abstractions. This class implements the MassTransit IConsumer interface and automatically routes incoming messages to a corresponding IInteractor, simplifying the implementation of message handlers by removing the need to manually invoke the interactor logic in every consumer.

src/Services/Identity/Command/Infrastructure.MessageBus/Abstractions · high confidence

The Event Store infrastructure now exposes dedicated configuration records for tuning behavior: EventStoreOptions allows users to set the snapshot interval (constrained between 3 and 100), while SqlServerRetryOptions provides control over retry logic, including maximum retry count (5–20), maximum retry delay, and a list of specific error numbers to include in retry attempts. These options are implemented as immutable records with validation attributes to ensure safe and predictable dependency injection.

src/Services/Communication/Command/Infrastructure.EventStore/DependencyInjection/Options · high confidence

Added new domain value objects for Email, SMS, and push notifications (mobile and web) within the Communication service. These records implement the INotificationOption interface and include implicit conversion operators to accept data from corresponding DTOs, enabling seamless integration with the command layer.

src/Services/Communication/Command/Domain/ValueObject · high confidence

The system now exposes new abstractions for handling paginated data and query parameters. A new \IPagedResult\<T\>\ interface defines the structure for paginated responses, containing a list of items and metadata about the current page. The \Page\ record models pagination metadata (current page, size, and navigation flags) and includes implicit conversions to and from the protobuf representation. Additionally, a \Paging\ record standardizes request parameters, enforcing a default limit of 10 and an upper limit of 100, with built-in validation and implicit conversion to the protobuf format.

src/Contracts/Abstractions/Paging · high confidence

Added new domain entities and enumerations to support the communication service's command side. This includes the \NotificationMethod\ entity, which tracks individual notification delivery attempts with states like Pending, Sent, Failed, and Cancelled, along with a corresponding validator. Additionally, \NotificationMethodStatus\ and \NotificationStatus\ smart enums were introduced to provide strongly-typed, serializable status tracking for both individual methods and broader notification contexts.

src/Services/Communication/Command/Domain/Entities · high confidence

The catalog command domain now uses dedicated \Currency\ and \Money\ value objects to handle financial data. The \Currency\ record defines supported currencies (such as USD, EUR, and BRL) with their ISO codes, symbols, and specific culture info for formatting, replacing the previous 'Unknown' state with an 'Undefined' default. The \Money\ record encapsulates an amount and its associated currency, enforcing that arithmetic operations (addition, subtraction, multiplication, division) and comparisons only occur between amounts in the same currency. These objects provide implicit conversions to and from the \Dto.Money\ type, ensuring consistent formatting and parsing across the service boundary.

src/Services/Catalog/Command/Domain/ValueObjects, src/Services/Order/Command/Domain/ValueObjects · high confidence

The Account Query service now exposes a new gRPC endpoint that handles account details retrieval, account listing, and shipping address listing. This service is built on .NET 8 and utilizes an interactor-based architecture to process queries, with configuration for MongoDB projections and RabbitMQ event bus connections provided via environment-specific settings.

src/Services/Account/Query/GrpcService · high confidence

A new gRPC service has been introduced to handle communication query operations, specifically exposing a \ListNotificationsDetails\ endpoint that retrieves paginated notification data via an \IPagedInteractor\. The service is built on .NET 8 (using ASP.NET Core 8.0-preview images) and includes full infrastructure wiring: dependency injection for interactors, projections, and event bus (MassTransit), along with Serilog-based request logging and HTTP/2 Kestrel configuration. It is containerized via a multi-stage Dockerfile and configured for Development, Staging, and Production environments with distinct MongoDB and RabbitMQ connection strings.

src/Services/Communication/Query/GrpcService · high confidence

The payment command service now includes a new Event Store implementation located in the Infrastructure.EventStore module. This introduces an EventStoreGateway that manages aggregate persistence, including automatic snapshotting based on a configurable interval, and an EventStoreRepository that handles the underlying Entity Framework Core operations for storing events and snapshots. Additionally, a UnitOfWork class is provided to manage database transactions for these operations.

src/Services/Payment/Command/Infrastructure.EventStore · high confidence

The ShoppingCart command service now uses a dedicated Event Store implementation to manage aggregate state. This includes an EventStoreGateway that handles loading aggregates from snapshots and event streams, appending new events, and automatically creating snapshots based on a configurable interval. The underlying persistence is provided by an EventStoreRepository backed by Entity Framework Core, which stores events and snapshots in the database. A UnitOfWork implementation wraps database operations in transactions to ensure consistency when persisting events.

src/Services/Order/Command/Infrastructure.EventStore, src/Services/ShoppingCart/Command/Infrastructure.EventStore, src/Services/Warehouse/Command/Infrastructure.EventStore · high confidence

The Communication command service now includes a new Event Store implementation consisting of an EventStoreGateway, EventStoreRepository, and UnitOfWork. The gateway handles appending events and snapshots to the repository, loading aggregates from history, and streaming aggregate IDs. The repository provides persistence operations using Entity Framework Core, including adding events and snapshots, retrieving event streams with versioning, fetching the latest snapshot, and listing distinct aggregate IDs. The UnitOfWork wraps database operations in transactions using EF Core's execution strategy.

src/Services/Communication/Command/Infrastructure.EventStore · high confidence

The Catalog command service now includes a new Event Store implementation featuring an EventStoreGateway that handles event persistence with automatic snapshotting based on a configurable interval, an EventStoreRepository backed by Entity Framework Core for storing events and snapshots, and a UnitOfWork implementation that wraps operations in database transactions using execution strategies.

src/Services/Catalog/Command/Infrastructure.EventStore · high confidence

The Identity command service now includes a dedicated Event Store context that persists domain events and aggregate snapshots to the database. This change introduces EF Core configurations for StoreEvent and Snapshot entities, ensuring that events and snapshots are stored with versioning, aggregate identifiers, and timestamps. To support this, new value converters handle the serialization and deserialization of aggregate roots and domain events using JSON.NET, including specific handling for DateOnly types. This provides the underlying storage mechanism for the event sourcing architecture within the Identity service.

src/Services/Identity/Command/Infrastructure.EventStore/Contexts · high confidence

A new gRPC service has been introduced in the Identity Query stack to handle user login queries. This service exposes a Login endpoint that delegates to an interactor, returning user details or a 'not found' response. The implementation is containerized via a new Dockerfile targeting .NET 8 and includes configuration for development, staging, and production environments, along with dependency injection setup for gRPC, event bus, JWT authentication, and Serilog logging.

src/Services/Identity/Query/GrpcService · high confidence

The Identity service now exposes a new set of command, query, and event contracts alongside a gRPC interface. Users can now send commands to register users, change or confirm emails, change passwords, define a primary email, and delete accounts. The service defines domain events for user lifecycle changes (registration, deletion, email/password changes) and delayed events for email confirmation expiration. A new gRPC service, IdentityService, exposes a Login RPC that accepts email and password, returning user details (ID, name, email, token) via a protobuf projection that includes an implicit conversion from the internal domain model.

src/Contracts/Services/Identity · high confidence

This change introduces a new MongoDB-based projection layer for the Account and ShoppingCart query services. It adds shared abstractions (IMongoDbContext and MongoDbContext) to handle database connections via a 'Projections' connection string, and registers the necessary dependency injection services (including ProjectionGateway and Bson serializers) for the ShoppingCart service. This provides a standardized way to access MongoDB collections for read-model projections in these specific services.

src/Services/Account/Query/Infrastructure.Projections/Abstractions, src/Services/ShoppingCart/Query/Infrastructure.Projections/Abstractions, src/Services/ShoppingCart/Query/Infrastructure.Projections/DependencyInjection · high confidence

A new gRPC service has been added to the Order domain to handle read-side queries. It exposes two endpoints: one to retrieve specific order details and another to list orders in a paginated grid view. The service is built on .NET 8, uses Serilog for logging, and integrates with MassTransit for event bus communication and MongoDB for storing order projections. Configuration is provided for development, staging, and production environments, including connection strings for MongoDB and RabbitMQ.

src/Services/Order/Query/GrpcService · high confidence

The Order aggregate in the Command domain has been introduced to manage order lifecycle events. It now handles PlaceOrder and ConfirmOrder commands by raising corresponding domain events (OrderPlaced, OrderConfirmed) and applies these events to update state, including items, payment methods, and status. A dedicated OrderValidator enforces business rules, ensuring the order ID is present, items are valid, and the total amount is greater than zero when active items exist.

src/Services/Order/Command/Domain/Aggregates · high confidence

The SMTP infrastructure layer now includes a new EmailGateway class that implements the IEmailGateway interface, enabling asynchronous email sending via SmtpClient with configurable options and detailed status tracking (Pending, Sent, Failed, Cancelled). Additionally, a LazyFactory\<T\> class has been added to support lazy initialization of services through the ILazy\<T\> interface, improving dependency injection patterns within the SMTP infrastructure.

src/Services/Communication/Command/Infrastructure.SMTP · high confidence

The Identity service now includes a new User aggregate root that manages user registration, password changes, and email lifecycle operations (confirmation, expiration, and primary email definition) via domain events. This change introduces a UserValidator enforcing specific constraints (e.g., password complexity, name length) and an EmailStatus enumeration to track the state of user emails, establishing the core domain model for identity management.

src/Services/Identity/Command/Domain/Aggregates · high confidence

The Communication service now exposes a defined set of command, query, and domain event contracts to handle notification workflows. Commands allow requesting, sending, failing, cancelling, and resetting notification methods, while domain events track the lifecycle of notifications and their methods with versioning. A new query supports listing notification details with paging, and protobuf definitions along with projection mappings enable serialization and data transfer for these entities.

src/Contracts/Services/Communication · high confidence

The Order Command application layer now includes a dedicated dependency injection setup. This change registers the core IApplicationService and introduces specific interactor registrations for order processing events, including PlaceOrderWhenCartSubmittedInteractor and ConfirmOrderWhenPaymentCompletedInteractor, making these components available for injection within the application service container.

src/Services/Order/Command/Application/DependencyInjection · high confidence

A new ServiceCollectionExtensions class has been introduced to centralize the registration of application-layer services within the Communication command module. This change adds scoped registrations for IApplicationService and INotificationService, as well as specific event interactors (RequestNotificationWhenUserRegisteredInteractor and SendNotificationWhenNotificationRequestedInteractor), enabling the application to resolve these dependencies via the standard DI container.

src/Services/Communication/Command/Application/DependencyInjection · high confidence

The shopping cart command domain now includes dedicated entity classes for CartItem and PaymentMethod, each with corresponding FluentValidation validators. CartItem tracks product, quantity, and unit price, while PaymentMethod stores the transaction amount and supports multiple payment options (CreditCard, DebitCard, PayPal) via an IPaymentOption interface. Implicit conversions are provided between these domain entities and their respective DTOs to facilitate data transfer.

src/Services/ShoppingCart/Command/Domain/Entities · high confidence

The Order Query service now includes a dedicated event bus implementation using MassTransit and RabbitMQ. This adds a base consumer abstraction and a specific consumer for handling OrderPlaced and OrderConfirmed domain events to update project order details. The infrastructure configures RabbitMQ connections with retry policies, kebab-case endpoint naming, and Newtonsoft.Json serialization (including custom converters for DateOnly types). It also introduces contract validation via FluentValidation filters and comprehensive logging observers for message receive and consume lifecycle events.

src/Services/Order/Query/Infrastructure.EventBus · high confidence

Added new event bus consumers in the Account service to handle domain events. The \CreateAccountWhenUserRegisteredInteractor\ automatically creates an account when a user registers. Additionally, consumers for \AccountCreated\, \AccountDeleted\, \AccountActivated\, \AccountDeactivated\, \BillingAddressAdded\, and \ShippingAddressAdded\ events now trigger the projection of account details and address lists to the query side.

src/Services/Account/Command/Application/UseCases/Events, src/Services/Account/Query/Infrastructure.EventBus/Consumers · high confidence

Added a new interactor that listens for OrderPlaced and OrderConfirmed domain events to update the read-side projection. When an order is placed, it creates or replaces the full OrderDetails projection with data from the event (including ID, customer, totals, addresses, items, payment methods, status, and version). When an order is confirmed, it updates only the Status field of the existing projection, ensuring the query side reflects the latest order state.

src/Services/Order/Query/Application/UseCases/Events · high confidence

Added new interactor classes in the Identity service to handle specific domain and delayed events. AccountDeactivatedInteractor and AccountDeletedInteractor now process account termination by deleting the associated user aggregate. EmailConfirmedInteractor sets the confirmed email as primary, while EmailChangedInteractor and UserRegisteredInteractor schedule a delayed EmailConfirmationExpired event to expire the confirmation after 15 minutes. The EmailConfirmationExpiredInteractor handles the expiration by marking the email as expired.

src/Services/Identity/Command/Application/UseCases/Events · high confidence

Two new interactor classes have been added to handle specific domain events within the communication service. The \RequestNotificationWhenUserRegisteredInteractor\ now automatically triggers a welcome email notification when a new user registers, formatting the message with the user's name and a confirmation link. Additionally, the \SendNotificationWhenNotificationRequestedInteractor\ processes \NotificationRequested\ events by loading the relevant notification aggregate and dispatching it via the notification service, ensuring that queued notifications are actually sent.

src/Services/Communication/Command/Application/UseCases/Events · high confidence

Added two new application-layer interactors to handle payment lifecycle events: \RequestPaymentWhenOrderPlacedInteractor\ creates a new Payment aggregate and issues a RequestPayment command when an OrderPlaced event occurs, and \ProceedWithPaymentWhenRequestedInteractor\ authorizes the payment via the payment gateway and issues a ProceedWithPayment command when a PaymentRequested event occurs.

src/Services/Payment/Command/Application/UseCases/Events · high confidence

The shopping cart query stack now exposes a dedicated gRPC service (ShoppingCartGrpcService) that serves read operations for shopping cart details, customer cart details, shopping cart items, and payment methods. This service is built on .NET 8 (using ASP.NET Core 8.0-preview images) and relies on an interactor pattern backed by MongoDB projections and MassTransit for event bus communication. It includes Docker support, structured logging via Serilog, and environment-specific configurations for development, testing, staging, and production.

src/Services/ShoppingCart/Query/GrpcService · high confidence

Added new interactor classes for identity-related commands, including ChangeEmailInteractor, ChangePasswordInteractor, ConfirmEmailInteractor, and RegisterUserInteractor. These interactors handle user registration, email confirmation, password changes, and email updates by loading the user aggregate, applying the command, and appending events.

src/Services/Identity/Command/Application/UseCases/Commands · high confidence

The order query service now includes dedicated interactors for retrieving specific order details and listing orders for grid views. GetOrderDetailsInteractor handles single order lookups by delegating to the projection gateway, while ListOrdersGridItemsInteractor supports paginated retrieval of order grid items filtered by customer ID, returning structured paged results.

src/Services/Order/Query/Application/UseCases/Queries · high confidence

The Contracts/Abstractions/Messages area now defines a new set of interfaces and base types for the messaging system. Commands, queries, and events are explicitly typed via ICommand, IQuery, and IEvent (with specialized IVersionedEvent, IDomainEvent, and ISummaryEvent variants), all sharing a common IMessage base that includes a Timestamp. A base Message record provides a default Timestamp. Additionally, validation result types (ValidationResult, ContractValidationResult, BusinessValidationResult) are introduced to standardize how validation outcomes are represented.

src/Contracts/Abstractions/Messages · high confidence

Added consumer classes in the Account Command service to handle incoming message bus traffic for account operations. Specifically, new consumers now process commands to add billing and shipping addresses and to delete an account, delegating execution to their respective interactors. Additionally, a new consumer handles the UserRegistered domain event to trigger account creation, ensuring the system reacts appropriately to new user registrations.

src/Services/Account/Command/Infrastructure.MessageBus/Consumers · high confidence

The ShoppingCart service now includes dedicated message bus consumers to handle cart operations and related events. New command consumers have been added for actions such as creating, discarding, and checking out carts, as well as managing cart items, billing and shipping addresses, and payment methods (credit card, debit card, PayPal). Additionally, event consumers now handle cart submission upon checkout and the publication of cart projection rebuild notifications, ensuring these internal events are properly routed through the message bus infrastructure.

src/Services/ShoppingCart/Command/Infrastructure.MessageBus/Consumers · high confidence

Added dedicated message bus consumer classes for identity-related commands, including ChangeEmail, ChangePassword, ConfirmEmail, and RegisterUser. These consumers act as entry points in the message bus infrastructure, delegating incoming command messages to the appropriate application-layer interactor for processing.

src/Services/Identity/Command/Infrastructure.MessageBus/Consumers/Commands · high confidence

Added two new MassTransit consumer classes to handle domain events: \PlaceOrderWhenCartSubmittedConsumer\ listens for \ShoppingCart.SummaryEvent.CartSubmitted\ to trigger order creation, and \ConfirmOrderWhenPaymentCompletedConsumer\ listens for \Payment.DomainEvent.PaymentCompleted\ to confirm orders. These consumers delegate processing to their respective interactor implementations, establishing the infrastructure for reacting to cart submission and payment completion events within the order service.

src/Services/Order/Command/Infrastructure.MessageBus/Consumers · high confidence

A new interactor, ListNotificationsDetailsInteractor, has been added to handle queries for listing notification details. It implements the IPagedInteractor interface to support pagination and delegates the actual data retrieval to a projection gateway, returning a paginated result of notification details.

src/Services/Communication/Query/Application/UseCases/Queries · high confidence

The shopping cart now supports Credit Card, Debit Card, and PayPal as distinct payment options. This change introduces the \IPaymentOption\ interface and specific record types for each method, along with corresponding FluentValidation rules to ensure data integrity (e.g., valid expiration dates, non-empty holder names, and proper email/password formats). Implicit conversions are provided between these domain value objects and their Data Transfer Object (DTO) counterparts to facilitate seamless data flow.

src/Services/ShoppingCart/Command/Domain/ValueObjects/PaymentOptions · high confidence

The order query service now includes a dedicated \ProjectionDbContext\ for MongoDB configuration and a generic \ProjectionGateway\<TProjection\>\ that handles read-side data access. This gateway provides methods for retrieving, listing (with pagination), deleting, and updating projections, while also implementing optimistic concurrency control via version checks during updates and idempotent upsert operations that handle duplicate key conflicts gracefully.

src/Services/Order/Query/Infrastructure.Projections · high confidence

The read model now automatically synchronizes with user identity events. When a user is registered, deleted, or has their password changed, the system updates the corresponding user details projection to keep the query side consistent with the latest state.

src/Services/Identity/Query/Application/UseCases/Events · high confidence

The application now explicitly registers the service handlers for identity-related commands and domain events. Users can now interact with the system through new command-based workflows for registering users, changing or confirming email addresses, and changing passwords. Additionally, the system now processes domain events such as user registration, email changes, email confirmation, and account deactivation or deletion, ensuring that background processes and side effects are triggered correctly for these identity actions.

src/Services/Identity/Command/Application/DependencyInjection · high confidence

The payment service now exposes a new gRPC interface for retrieving payment details, payment method details, and listing payment methods. This change introduces Protobuf definitions for the service and its request/response messages, alongside C\# query records that deserialize gRPC requests and projection records that serialize domain data back into Protobuf responses, enabling clients to fetch payment state via the new API.

src/Contracts/Services/Payment · high confidence

The WebAPI layer now exposes versioned REST endpoints (v1 and v2) for core business domains including Accounts, Catalog, Communications, Identities, Orders, Payments, and Shopping Carts. Each domain is structured with dedicated API registration files, command and query records, and FluentValidation validators to enforce input constraints before requests are dispatched to the underlying gRPC services.

src/Web · high confidence

The Account domain aggregate now manages account lifecycle and address preferences through an event-sourced pattern. It handles commands to create, activate, and delete accounts, as well as add, prefer, delete, and restore billing and shipping addresses, raising corresponding domain events for each state change. The aggregate exposes addresses via a read-only collection and includes an AccountValidator to enforce that the account ID is present, the profile is valid, and all addresses meet validation rules.

src/Services/Account/Command/Domain/Aggregates · high confidence

The Account service's query use cases (GetAccount, ListAccounts, ListShippingAddresses) have been refactored to implement new interactor interfaces (IInteractor and IPagedInteractor). This change standardizes how these queries interact with the projection gateway, ensuring consistent handling of single-item and paginated results for account details and shipping addresses.

src/Services/Account/Query/Application/UseCases/Queries · high confidence

The Account service contracts have been restructured to support a new architectural design. This includes the introduction of a Protobuf definition (Account.proto) for service RPCs (GetAccountDetails, ListAccountsDetails, ListShippingAddressesListItems) and data projections, alongside C\# record types for Commands (e.g., CreateAccount, AddShippingAddress), DomainEvents (e.g., AccountCreated, BillingAddressAdded), Queries (e.g., GetAccountDetails), and Projections (e.g., AccountDetails). Implicit operators are added to facilitate conversion between the new C\# records and the Protobuf messages, ensuring seamless integration with the updated service interface.

src/Contracts/Services/Account · high confidence

The Account command service now exposes a new IApplicationService interface and its implementation, ApplicationService, which centralizes core event-sourcing operations. This service coordinates loading and appending aggregate events via the event store gateway and handles event publishing through the event bus gateway, ensuring that domain events are persisted and published within a single unit of work transaction.

src/Services/Account/Command/Application/Services · high confidence

The AccountStatus enumeration has been refactored to use Ardalis.SmartEnum, replacing previous implementation with a strongly-typed approach. This change introduces four distinct status values (Pending, Active, Inactive, Closed) with implicit conversions to and from strings and integers, ensuring type-safe account status handling within the account service domain.

src/Services/Account/Command/Domain/Enumerations · high confidence

New dependency-injection extension methods and MongoDB context abstractions have been added to the query infrastructure of the Account, Catalog, Communication, Identity, Order, Payment, and Warehouse services. Each service now registers the generic IProjectionGateway\<\> and IMongoDbContext implementations via its ServiceCollectionExtensions, and registers a BSON serializer for Guid types, enabling these services to read from their respective projection stores.

(repo-wide) · high confidence

New validators have been introduced for the Warehouse service to enforce data integrity on incoming commands. CreateInventoryValidator ensures that InventoryId and OwnerId are provided when creating an inventory record. ReceiveInventoryItemValidator validates that the received item has a positive Cost and Quantity, and delegates validation of the nested Product object to a dedicated ProductValidator.

src/Contracts/Services/Warehouse/Validators · high confidence

The Identity service now enforces specific input constraints for user registration and email confirmation. RegisterUserValidator ensures first and last names are between 4 and 30 characters and distinct, requires a valid email format, and mandates passwords be 8-16 characters long with at least one uppercase letter, one lowercase letter, one number, and one non-alphanumeric character. ConfirmEmailValidator ensures the user ID is present and the email is a valid, non-empty address.

src/Contracts/Services/Identity/Validators · high confidence

The shopping cart now enforces validation on address data, requiring city, country, state, street, and zip code to be present. Optional fields like number and complement are validated when provided, with number needing to be greater than zero and complement limited to 80 characters.

src/Services/ShoppingCart/Command/Domain/ValueObjects/Addresses · high confidence

The Catalog domain aggregate has been refactored to enforce stricter encapsulation: internal item storage is now a private list exposed via a read-only IEnumerable, preventing external mutation of the catalog's contents. The aggregate now explicitly handles commands for creating, deleting, activating, deactivating, and modifying catalog details, as well as adding, increasing, and removing items, raising corresponding domain events for each state change. A new validator ensures the catalog ID is present, the title is not null or empty, and all items conform to the catalog item validation rules.

src/Services/Catalog/Command/Domain/Aggregates · high confidence

The command handling logic for the Catalog service has been refactored to use a standardized Interactor pattern. New interactor classes (such as ActivateCatalogInteractor, CreateCatalogInteractor, and DeleteCatalogInteractor) now manage catalog operations by loading the Catalog aggregate via IApplicationService, applying the command through the aggregate's Handle method, and persisting resulting events. This change replaces the previous implementation approach with a consistent structure for all catalog command use cases.

src/Services/Catalog/Command/Application/UseCases/Commands · high confidence

The application now explicitly registers catalog command interactors (Activate, Add, ChangeDescription, ChangeTitle, Create, Deactivate, Delete, and RemoveCatalogItem) as scoped services. This wiring enables the application to resolve and execute these specific catalog management operations through the new DI configuration.

src/Services/Catalog/Command/Application/DependencyInjection · high confidence

The Catalog command service now uses MassTransit with RabbitMQ for message bus communication, replacing the previous implementation. This change introduces kebab-case naming for endpoints and entities, configures retry policies, and sets up JSON serialization with custom converters. The service also integrates Quartz for scheduling and adds validation filters for message contracts.

src/Services/Catalog/Command/Infrastructure.MessageBus/DependencyInjection · high confidence

The application layer for the Communication service now provides a centralized registration method, AddInteractors, which configures the dependency injection container. This method registers specific interactors for handling project notification details when a notification changes and for listing notification details, ensuring these query handlers are available as scoped services within the application.

src/Services/Communication/Query/Application/DependencyInjection · high confidence

The application now centralizes the dependency injection configuration for catalog interactors via a new \AddInteractors\ extension method. This method registers all event-driven interactors (handling catalog changes for grid items, item cards, details, and list items) and query interactors (for retrieving catalog item details and listing items/cards/grid items) as scoped services, simplifying the setup required to enable these capabilities.

src/Services/Catalog/Query/Application/DependencyInjection, src/Services/Order/Query/Application/DependencyInjection · high confidence

The warehouse query application layer now provides a dedicated DI extension method, AddInteractors, which registers the specific event and query interactors (such as inventory grid and list item handlers) as scoped services. This centralizes the wiring of these application components, replacing previous scattered registration patterns with a single entry point for the query stack's interactors.

src/Services/Account/Query/Application/DependencyInjection, src/Services/Warehouse/Query/Application/DependencyInjection · high confidence

The shopping cart query service now registers its interactors through a centralized DI extension method. This change consolidates the registration of query handlers (such as GetShoppingCartDetails and ListPaymentMethodsListItems) and event-driven interactors (such as ProjectCartDetailsWhenCartChanged) into a single entry point, simplifying how these components are wired into the application.

src/Services/ShoppingCart/Query/Application/DependencyInjection · high confidence

The ShoppingCart command service now registers its Event Store infrastructure via a new DI extension, wiring the event store gateway, repository, and unit of work. It introduces configurable options for SQL Server retry behavior (max retry count, delay, and error numbers) and snapshot intervals, allowing users to tune resilience and performance through configuration rather than hard-coded defaults.

src/Services/ShoppingCart/Command/Infrastructure.EventStore/DependencyInjection · high confidence

The Account command service now registers its message bus infrastructure using MassTransit with RabbitMQ. Endpoint names are standardized to kebab-case to ensure consistent queue and exchange naming. JSON serialization is configured to handle DateOnly and ExpirationDateOnly types, and retry policies are applied based on configuration. Additionally, the publish pipeline is updated to align the message correlation ID with the initiator ID, ensuring traceability across events.

src/Services/Account/Command/Infrastructure.MessageBus/DependencyInjection/Extensions · high confidence

The account query service now validates incoming event messages using FluentValidation. If a message fails validation, the system logs the errors and sends a structured failure report to a specific error queue (e.g., \queue:account.\[event-name\].contract-errors\) instead of processing the invalid message, ensuring that downstream consumers only receive valid data.

src/Services/Account/Query/Infrastructure.EventBus/PipeFilters, src/Services/Communication/Query/Infrastructure.EventBus/PipeFilters · high confidence

The Order Command service now registers the Event Store infrastructure via a new DI extension. This registers the event store gateway, repository, and unit of work as scoped services, and configures a pooled SQL Server DbContext with a configurable retry execution strategy. Configuration is driven by two new options records: EventStoreOptions (containing a required snapshot interval between 3 and 100) and SqlServerRetryOptions (containing required max retry count between 5 and 20, a required max retry delay, and an optional list of error numbers to add to the retry set).

src/Services/Order/Command/Infrastructure.EventStore/DependencyInjection · high confidence

The Event Store infrastructure now persists snapshots and events with explicit timestamps and uses EF Core value converters to serialize aggregate roots and domain events as JSON. This change introduces new entity configurations for Snapshot and StoreEvent, custom converters for serialization, and a dedicated DbContext, altering how event data is stored and retrieved.

src/Services/Payment/Command/Infrastructure.EventStore/Contexts · high confidence

The Event Store's database schema and persistence logic have been updated to include a \Timestamp\ field on both \Snapshot\ and \StoreEvent\ entities, ensuring temporal tracking for stored data. This change introduces new Entity Framework Core configuration classes (\SnapshotConfiguration\, \StoreEventConfiguration\) and value converters (\AggregateConverter\, \EventConverter\) that handle JSON serialization of domain aggregates and events, while the \EventStoreDbContext\ now enforces specific string constraints (non-Unicode, max length 1024) for the underlying storage.

src/Services/Warehouse/Command/Infrastructure.EventStore/Contexts · high confidence

The shopping cart service now publishes specific summary events in response to internal domain and notification events. When a cart is checked out, the system loads the cart aggregate and publishes a CartSubmitted event containing the cart data and its version. Similarly, when a cart projection rebuild is requested, the system publishes a CartProjectionRebuilt event with the current cart state and version. These changes enable downstream consumers to react to cart state changes and projection updates via an event-driven architecture.

src/Services/ShoppingCart/Command/Application/UseCases/Events · high confidence

The query-side read model now automatically updates inventory projections in response to domain events. A new interactor handles \InventoryCreated\ events by inserting or replacing \InventoryGridItem\ records, while another interactor processes \InventoryAdjustmentDecreased\, \InventoryAdjustmentIncreased\, \InventoryItemIncreased\, and \InventoryItemReceived\ events to update or create \InventoryItemListItem\ records. These changes ensure that the warehouse inventory views remain consistent with the latest state by propagating version information and using upsert/field-update operations via the projection gateway.

src/Services/Warehouse/Query/Application/UseCases/Events · high confidence

The Identity Command service now registers its EventStore infrastructure dependencies via a new \AddEventStore\ extension method. This registers the \IEventStoreGateway\, \IEventStoreRepository\, and \IUnitOfWork\ implementations as scoped services. It also configures a pooled \EventStoreDbContext\ using SQL Server, enabling detailed error logging and sensitive data logging, and applies a configurable retry execution strategy via \SqlServerRetryOptions\. Additionally, it provides configuration helpers to bind and validate \SqlServerRetryOptions\ and \EventStoreOptions\ from the application configuration.

src/Services/Identity/Command/Infrastructure.EventStore/DependencyInjection/Extensions · high confidence

The identity query service's event bus wiring has been refactored to use explicit MassTransit configuration rather than auto-discovery. RabbitMQ receive endpoints are now named using a kebab-case convention (e.g., \identity.query-stack.project-user-details-when-user-changed.user-deleted\) and are bound explicitly to specific domain events (\UserDeleted\, \UserRegistered\, \UserPasswordChanged\) via the \ProjectUserDetailsWhenUserChangedConsumer\. The bus setup now enforces a required \ConnectionName\ in configuration, applies incremental retry policies, and uses Newtonsoft.Json with custom converters for \DateOnly\ and \ExpirationDateOnly\. Additionally, incoming messages are validated via a \ContractValidatorFilter\ that routes validation failures to a dedicated error queue.

src/Services/Identity/Query/Infrastructure.EventBus/DependencyInjection · high confidence

The Identity Command service now explicitly configures its MassTransit RabbitMQ integration, including kebab-case endpoint naming, specific JSON serialization settings (Newtonsoft.Json with custom converters for DateOnly and type handling), and retry policies. It registers dedicated receive endpoints for identity-related domain events (AccountDeactivated, AccountDeleted, EmailConfirmationExpired, EmailConfirmed, UserRegistered) and ensures correlation IDs are propagated from initiator IDs during event publishing. Additionally, it registers the EventBusGateway and message validators.

src/Services/Identity/Command/Infrastructure.MessageBus/DependencyInjection/Extensions · high confidence

The PagedResult class has been introduced across multiple query services (Catalog, Communication, Identity, Order, Payment, and Warehouse) to provide a consistent, immutable pagination wrapper. This implementation ensures that the returned item list is read-only and calculates page metadata (current page, size, next/previous availability) based on the applied limit and offset, improving data integrity for consumers of these query projections.

(repo-wide) · high confidence

The Account and ShoppingCart query services now use a new \PagedResult\ implementation that enforces immutability on paginated data. By storing items in a read-only list and exposing them via \AsReadOnly()\, the system prevents accidental modification of query results after retrieval, ensuring data consistency for consumers of the Account and ShoppingCart projection APIs.

src/Services/Account/Query/Infrastructure.Projections/Pagination, src/Services/ShoppingCart/Query/Infrastructure.Projections/Pagination · high confidence

The ShoppingCart service's Event Store migration now establishes the foundational database structure. It creates the 'Events' and 'Snapshots' tables to persist domain events and aggregate snapshots, including a new 'Timestamp' column for both entities to track when data was recorded. Additionally, the migration provisions the 'Quartz' database and its associated tables (such as QRTZ\_JOB\_DETAILS, QRTZ\_TRIGGERS, and QRTZ\_CALENDARS) to support background job scheduling.

src/Services/ShoppingCart/Command/Infrastructure.EventStore/Migrations · high confidence

The Catalog Query service is now implemented as a new .NET 8 gRPC application, replacing the previous approach. It exposes endpoints for retrieving catalog item details and listing items in grid, card, and list views, delegating to specific interactors for each operation. The service is containerized via a new Dockerfile targeting .NET 8.0-preview and includes configuration for Serilog, MassTransit event bus, and MongoDB projections, with environment-specific settings for local, staging, and production connections.

src/Services/Catalog/Query/GrpcService · high confidence

The Payment Query service is now implemented as a standalone .NET 8 gRPC application, replacing the previous iteration. This change introduces a new service boundary that exposes payment and payment method details via gRPC, backed by an event bus (MassTransit) and MongoDB projections. The service is containerized with a new Dockerfile and .dockerignore, and configured for development, staging, and production environments with specific connection strings for MongoDB and RabbitMQ. Key architectural shifts include the use of IPagedInteractor for list operations, correlation ID handling, and a shift from IP-based localhost references to hostname-based service discovery in non-development environments.

src/Services/Payment/Query/GrpcService · high confidence

The payment domain now uses \Ardalis.SmartEnum\-based types for status tracking, replacing previous implementations. \PaymentMethodStatus\ defines specific lifecycle states for payment methods (Pending, Authorized, Cancelled, CancellationDenied, Denied, RefundDenied, Refunded), while \PaymentStatus\ tracks the overall payment state (Empty, Ready, Completed, NotCompleted, Cancelled, Refunded). Both enums support implicit conversions to and from strings and integers, ensuring consistent serialization and comparison across the command stack.

src/Services/Payment/Command/Domain/Enumerations · high confidence

The Catalog command application layer now exposes an ApplicationService that centralizes aggregate loading, event persistence, and event publishing. This service coordinates with the event store and event bus, ensuring that appending events to an aggregate is wrapped in a unit of work before publishing uncommitted events to the bus, and provides utilities for streaming aggregate IDs and scheduling delayed events.

src/Services/Catalog/Command/Application/Services · high confidence

The payment command domain layer now uses dedicated value objects to model core entities, replacing primitive types with structured data. This includes an Address value object with validation rules for required fields, a Currency record supporting multiple ISO codes and culture-specific formatting, and a Money record that enforces currency consistency during arithmetic operations. Payment methods are also modeled as value objects (CreditCard, DebitCard, PayPal) implementing a common IPaymentOption interface, each with corresponding FluentValidation rules to ensure data integrity before processing.

src/Services/Payment/Command/Domain/ValueObjects · high confidence

The Communication service now defines a new \IEventStoreRepository\ interface along with \StoreEvent\ and \Snapshot\ record types to standardize how domain events and aggregate snapshots are persisted and retrieved. This change provides a cleaner, more explicit contract for appending events and snapshots, as well as retrieving stream history and current snapshots, replacing previous ad-hoc or less structured mechanisms within the command domain.

src/Services/Catalog/Command/Domain/Abstractions/EventStore, src/Services/Communication/Command/Domain/Abstractions/EventStore · high confidence

The ShoppingCart command domain now defines a dedicated event store contract (IEventStoreRepository) alongside new data models (StoreEvent, Snapshot). This provides a standardized mechanism for appending events and snapshots, retrieving stream history, and enumerating aggregate IDs, replacing the previous ad-hoc or UnitOfWork-based persistence approach with a consistent, queryable event-sourcing interface.

src/Services/ShoppingCart/Command/Domain/Abstractions/EventStore · high confidence

The Order Query service now exposes a new set of application-layer abstractions to standardize how queries are handled and how data projections are managed. The new \IInteractor\ interface (including a specialized \IPagedInteractor\) defines the contract for processing queries and events, replacing previous ad-hoc patterns. Additionally, \IProjectionGateway\ provides a unified API for finding, listing, creating, updating, and deleting projections, including support for versioned field updates and bulk operations like \ReplaceInsertAsync\ and \RebuildInsertAsync\. These interfaces form the foundation for the segregated command and query stacks, enabling more predictable and testable data access patterns within the read side of the application.

src/Services/Communication/Query/Application/Abstractions, src/Services/Identity/Query/Application/Abstractions, src/Services/Order/Query/Application/Abstractions · high confidence

The payment command domain layer now includes new base classes \Entity\<TValidator\>\ and \AggregateRoot\<TValidator\>\ that enforce validation on creation and state changes. \AggregateRoot\ manages versioning and exposes uncommitted domain events as a read-only collection, ensuring that event history cannot be modified externally. This change establishes a stricter foundation for domain models by integrating FluentValidation directly into the entity lifecycle.

src/Services/Payment/Command/Domain/Abstractions/Aggregates · high confidence

The Warehouse Query application layer now defines new interfaces to standardize how queries are handled and how projections are accessed. IInteractor provides generic contracts for processing events, executing queries against projections, and handling paginated query results. IProjectionGateway exposes specific operations for finding, listing, updating, and deleting projections, including support for versioned field updates and idempotent insert/replace operations.

src/Services/Warehouse/Query/Application/Abstractions · high confidence

The Warehouse command application layer now exposes a new IApplicationService interface and its implementation, centralizing core event-sourcing capabilities. This service provides methods to load aggregates, append events (coordinating persistence and event bus publishing via a UnitOfWork), stream aggregate IDs, and publish or schedule events, effectively replacing previous fragmented gateway usage with a single, consistent application-facing API.

src/Services/Warehouse/Command/Application/Services · high confidence

The Account service now exposes a dedicated Event Store interface (IEventStoreRepository) and supporting data structures (StoreEvent, Snapshot) within the domain abstractions layer. This change defines the contract for persisting domain events and snapshots, including methods to append events and snapshots, retrieve streams by aggregate ID, and enumerate aggregate IDs, establishing the foundational mechanism for event sourcing in this service.

src/Services/Account/Command/Domain/Abstractions/EventStore · high confidence

The PaymentMethod entity has been introduced to the domain layer, replacing primitive types with a Money value object for the amount and an IPaymentOption interface to support CreditCard, DebitCard, and PayPal payment types. The entity includes lifecycle methods for authorizing, denying, canceling, and refunding payments, along with implicit conversion operators to and from Data Transfer Objects to facilitate integration with the service layer.

src/Services/Payment/Command/Domain/Entities · high confidence

The shopping cart command application layer now exposes a unified \IApplicationService\ interface and its \ApplicationService\ implementation. This service centralizes core event-sourcing capabilities, including loading and appending aggregate events via the event store, publishing events to the bus, and scheduling delayed events, while managing database transactions through a unit of work.

src/Services/ShoppingCart/Command/Application/Services · high confidence

The domain layer now includes a new abstract \Entity\<TValidator\>\ base class and an \IEntity\ interface. This change introduces a generic mechanism where domain entities automatically validate themselves using a specified FluentValidation validator upon invocation of the \Validate()\ method, ensuring data integrity at the entity level before state changes are persisted.

src/Services/Identity/Command/Domain/Abstractions/Entities · high confidence

The Identity Command service now uses immutable C\# records for its dependency injection options, specifically introducing \EventStoreOptions\ and \SqlServerRetryOptions\. \EventStoreOptions\ enforces a snapshot interval between 3 and 100, while \SqlServerRetryOptions\ configures retry behavior with a max count of 5–20, a timestamped max delay, and optional specific error numbers. This change improves configuration safety and immutability within the Event Store infrastructure layer.

src/Services/Identity/Command/Infrastructure.EventStore/DependencyInjection/Options · high confidence

The Order service's command-side domain layer now includes new base abstractions for aggregate roots. The \AggregateRoot\<TValidator\>\ class provides a generic foundation that manages versioning, applies domain events from history, and exposes uncommitted events as a read-only collection, while enforcing validation upon event application. The accompanying \IAggregateRoot\ interface defines the contract for these aggregates, ensuring they can handle commands and load their state from event history. This change establishes the structural basis for the new event-sourcing design within the Order command stack.

src/Services/Order/Command/Domain/Abstractions/Aggregates · high confidence

The Account service's application layer now exposes a set of new interfaces to support a redesigned architecture. Specifically, \IEventBusGateway\ and \IEventStoreGateway\ define contracts for publishing events and managing aggregate persistence, while \IInteractor\ standardizes message handling and \IUnitOfWork\ provides a mechanism for executing operations within a transactional scope. These abstractions decouple the service's command logic from specific infrastructure implementations.

src/Services/Account/Command/Application/Abstractions, src/Services/Order/Command/Application/Abstractions · high confidence

The Communication service's command domain now utilizes a new set of base abstractions for entities and aggregate roots. The \Entity\ base class introduces automatic validation via FluentValidation and tracks deletion status, while the \AggregateRoot\ base class manages versioning, handles event replay through \LoadFromHistory\, and provides a structured mechanism for raising and storing uncommitted domain events. These changes establish a standardized foundation for domain models within this service.

src/Services/Communication/Command/Domain/Abstractions/Aggregates · high confidence

The Account service now utilizes a new domain design by introducing base classes for entities and aggregate roots. The new \Entity\<TValidator\>\ base class provides a generic mechanism for automatic validation using FluentValidation, ensuring entities are validated upon state changes. The \AggregateRoot\<TValidator\>\ class builds on this to manage domain events, exposing uncommitted events as a read-only collection and handling versioning. This change establishes the foundational structure for how domain objects are created, validated, and tracked for event sourcing within the Account service.

src/Services/Account/Command/Domain/Abstractions/Aggregates · high confidence

The application layer now exposes two new interfaces, IEventBusGateway and IEventStoreGateway, to handle infrastructure communication. IEventBusGateway provides methods for publishing single or multiple events and scheduling delayed events, while IEventStoreGateway defines operations for appending events to aggregates, loading aggregates by ID, and streaming aggregate IDs. These abstractions decouple the identity command logic from specific event handling implementations.

src/Services/Identity/Command/Application/Abstractions/Gateways · high confidence

A new \MessageBusOptions\ record has been added to define the configuration contract for the shopping cart's message bus infrastructure. This change introduces required properties for connection details (\ConnectionName\, \ConnectionString\) and retry/scheduling behavior (\RetryLimit\, \InitialInterval\, \IntervalIncrement\, \SchedulerQueueName\), enforcing validation rules such as range limits and minimum string lengths directly on the configuration model.

src/Services/Account/Command/Infrastructure.MessageBus/DependencyInjection/Options, src/Services/ShoppingCart/Command/Infrastructure.MessageBus/DependencyInjection/Options · high confidence

The Account service now uses dedicated options records to manage infrastructure settings, replacing previous implicit or loosely-typed configurations. EventStoreOptions enforces a SnapshotInterval between 3 and 100, while SqlServerRetryOptions defines MaxRetryCount (5–20), MaxRetryDelay, and optional ErrorNumbersToAdd, ensuring these values are validated at startup via Data Annotations.

src/Services/Account/Command/Infrastructure.EventStore/DependencyInjection/Options · high confidence

The message bus infrastructure now uses a dedicated \MessageBusOptions\ record to enforce strict configuration validation. This change introduces required properties for the connection name and URI, along with validated settings for retry logic (limit between 1-10, initial interval, and increment) and the scheduler queue name (minimum length 5). By switching to immutable records with data annotations, the system ensures that these critical communication parameters are validated at startup, preventing runtime errors caused by missing or invalid configuration values.

src/Services/Communication/Command/Infrastructure.MessageBus/DependencyInjection/Options, src/Services/Identity/Command/Infrastructure.MessageBus/DependencyInjection/Options · high confidence

The shopping cart domain now uses dedicated \Money\ and \Currency\ value objects to handle financial data. \Currency\ provides a set of predefined ISO codes (such as USD, EUR, BRL) with associated symbols and culture info, replacing the previous 'Unknown' state with an 'Undefined' constant. \Money\ wraps a decimal amount with a \Currency\ instance, enforcing that arithmetic operations (addition, subtraction, multiplication, division) and comparisons only occur between amounts in the same currency. Implicit conversions allow seamless integration with existing DTOs, ensuring that monetary values are formatted and parsed according to the specific currency's culture settings.

src/Services/ShoppingCart/Command/Domain/ValueObjects · high confidence

The message bus infrastructure now formats endpoint and entity names using kebab-case (e.g., \communication.command-stack.{consumer}.{event}\) instead of the previous naming convention, which may require queue name adjustments during migration. Additionally, RabbitMQ connections are now explicitly named using a combination of the configured connection name and the application's friendly name, improving connection identification in the broker. The system also enforces a rule where published events inherit the initiator ID as their correlation ID, ensuring consistent traceability across the communication stack.

src/Services/Communication/Command/Infrastructure.MessageBus/DependencyInjection/Extensions · high confidence

The HTTP infrastructure layer for the Payment Command service has been replaced with a new implementation. This change introduces dedicated HTTP clients and payment services for Credit Cards, Debit Cards, and PayPal, which now rely on strongly-typed configuration options (e.g., \CreditCardHttpClientOptions\) for endpoints and timeouts. Dependency injection has been updated to register these services via new extension methods (\AddCreditCardHttpClient\, \AddDebitCardHttpClient\, \AddPayPalHttpClient\) that configure \HttpClient\ instances with Polly-based retry and circuit-breaker policies. This refactors how the system communicates with external payment providers, moving from the previous implementation to this new structured approach.

src/Services/Payment/Command/Infrastructure.HTTP · high confidence

The application layer for warehouse commands has been refactored to use a new interactor pattern. New interactor classes (CreateInventoryInteractor, DecreaseInventoryAdjustInteractor, IncreaseInventoryAdjustInteractor, ReceiveInventoryItemInteractor) now handle command execution by loading or creating inventory aggregates, applying the command via a Handle method, and appending resulting events through the IApplicationService. This changes how command processing is structured internally, moving logic into dedicated interactor implementations that implement IInteractor\<CommandType\>.

src/Services/Warehouse/Command/Application/UseCases/Commands · high confidence

The Payment Query service's event bus infrastructure has been replaced with a new implementation using MassTransit and RabbitMQ. This change introduces a generic consumer base class and specific consumers for payment domain events (such as PaymentRequested, PaymentCanceled, and various PaymentMethod events), routing them through a lazy interactor provider. The configuration now enforces kebab-case endpoint naming, adds incremental retry policies, and integrates FluentValidation via a pipe filter to reject invalid messages. Additionally, comprehensive logging observers have been added to track message receive and consume lifecycle events, including correlation IDs and timing.

src/Services/Payment/Query/Infrastructure.EventBus · high confidence

The Order Command stack now includes a new Address value object that defines core address fields (street, city, state, zip code, country, optional number, and optional complement). It provides implicit conversions to and from the Dto.Address type and defines equality checks against that DTO. An accompanying validator enforces that city, country, state, street, and zip code are present and non-empty, requires the number to be greater than zero when provided, and limits the complement to 80 characters when provided.

src/Services/Order/Command/Domain/ValueObjects/Addresses · high confidence

The Payment command domain introduces a new set of abstractions for event sourcing, including the IEventStoreRepository interface, the StoreEvent record, and the Snapshot record. These components define the contract for appending events and snapshots, retrieving stream history, and managing aggregate state versions, establishing the foundational infrastructure for the domain's event storage mechanism.

src/Services/Payment/Command/Domain/Abstractions/EventStore · high confidence

The Account service now uses a new Event Store infrastructure to handle domain events and snapshots. This includes an EventStoreGateway that manages appending events and snapshots (triggered by a configurable interval) and loading aggregates from their event history, as well as an EventStoreRepository that persists these events and snapshots to a database context.

src/Services/Account/Command/Infrastructure.EventStore · high confidence

The Identity command service now includes a new Event Store implementation consisting of three core components: EventStoreRepository handles persistence of domain events and snapshots via Entity Framework Core; EventStoreGateway orchestrates loading aggregates (with snapshot optimization) and appending new events; and UnitOfWork provides transactional execution for database operations. This replaces the previous event store mechanism with a cleaner design that separates repository concerns from gateway orchestration.

src/Services/Identity/Command/Infrastructure.EventStore · high confidence

The Catalog command service now persists domain state using a dedicated EventStoreDbContext that stores both StoreEvent and Snapshot entities. Snapshots include a new Timestamp property to track when the state was captured, and both events and snapshots are serialized using custom EF Core value converters (AggregateConverter and EventConverter) that handle JSON serialization with type information and specific date-only converters. This change introduces the underlying storage mechanism for the event sourcing approach, enabling the system to reconstruct aggregate state from events and snapshots.

src/Services/Catalog/Command/Infrastructure.EventStore/Contexts · high confidence

The Payment command service now registers its EventStore infrastructure via a new DI extension. This adds scoped services for the event store gateway, repository, and unit of work, and configures a pooled SQL Server DbContext with a custom retry execution strategy. Configuration is driven by new strongly-typed options: EventStoreOptions (controlling snapshot interval) and SqlServerRetryOptions (controlling max retry count, delay, and error numbers).

src/Services/Payment/Command/Infrastructure.EventStore/DependencyInjection · high confidence

The Warehouse Command service now registers its EventStore infrastructure via a new DI extension. This adds scoped services for the event store gateway, repository, and unit of work, and configures a pooled SQL Server DbContext with detailed error logging and a configurable retry execution strategy. Users can now tune the retry behavior (max count, delay, and specific error numbers) via SqlServerRetryOptions and control event snapshotting frequency via the new EventStoreOptions (snapshot interval).

src/Services/Catalog/Command/Infrastructure.EventStore/DependencyInjection, src/Services/Warehouse/Command/Infrastructure.EventStore/DependencyInjection · high confidence

The ShoppingCart query service introduces new interface definitions to standardize how queries are processed and how projection data is managed. IInteractor defines generic contracts for handling events and queries, including a specific interface for paginated results, while IProjectionGateway provides a unified API for finding, listing, updating, and deleting projection records. These abstractions decouple the query logic from the underlying data access implementation, allowing for more flexible and testable read-side operations.

src/Services/Catalog/Query/Application/Abstractions, src/Services/ShoppingCart/Query/Application/Abstractions · high confidence

The Account Query service introduces new interface definitions to standardize how queries are processed and how read-model projections are managed. The \IInteractor\ interface (including a paged variant) now defines the contract for handling queries and events, while \IProjectionGateway\ provides methods for finding, listing, updating, and deleting projections. Additionally, \IJwtTokenGenerator\ and \IPasswordHasher\ interfaces are added to support authentication and security operations within the query stack.

src/Services/Account/Query/Application/Abstractions · high confidence

The \src/Contracts/Abstractions\ module now includes a new \Abstractions.proto\ file defining shared Protobuf message types for generic responses (\GetResponse\, \ListResponse\), pagination (\PagedResult\, \Page\, \Paging\), and domain entities such as \Money\, \Product\, \Address\, and payment options (\CreditCard\, \DebitCard\, \PayPal\). Additionally, a new \IProjection\ C\# interface is introduced, establishing a common contract for projection entities with \Id\, \IsDeleted\, and \Version\ properties.

src/Contracts/Abstractions · high confidence

The Identity service now introduces a new domain abstraction layer for aggregate roots, providing a standardized base class and interface for entities that use event sourcing. This new design includes automatic version tracking, a mechanism to load state from historical events, and a safe way to raise and apply domain events while ensuring validation occurs before events are committed. Users interacting with the Identity service's command model will benefit from a more consistent and robust foundation for handling state changes and event history.

src/Services/Catalog/Command/Domain/Abstractions/Aggregates, src/Services/Identity/Command/Domain/Abstractions/Aggregates · high confidence

The Account service now includes dedicated command interactors for adding billing addresses, adding shipping addresses, and deleting accounts. These new components implement the application's command pattern, loading the relevant account aggregate, handling the specific command, and appending resulting events via the application service.

src/Services/Account/Command/Application/UseCases/Commands · high confidence

A new ServiceCollectionExtensions file has been added to register the Account service's command and event interactors. This change wires up specific use cases—AddBillingAddress, AddShippingAddress, DeleteAccount, and CreateAccountWhenUserRegistered—into the dependency injection container, replacing the previous registration mechanism with this new structured approach.

src/Services/Account/Command/Application/DependencyInjection · high confidence

The ShoppingCart command application layer now registers its service dependencies via a new \ServiceCollectionExtensions\ file. This change introduces explicit DI registrations for command interactors (such as adding billing/shipping addresses, managing cart items, checking out, and removing payment methods) and event interactors (publishing cart submitted and projection rebuilt events), replacing the previous implicit or manual wiring with a structured \AddCommandInteractors\ and \AddEventInteractors\ setup.

src/Services/ShoppingCart/Command/Application/DependencyInjection · high confidence

The application layer now explicitly registers its command and event interactors via new extension methods. \AddCommandInteractors\ binds specific handlers for inventory operations (creating inventory, increasing/decreasing inventory adjustments, and receiving items) to the \IInteractor\ interface, while \AddEventInteractors\ registers the logic to reserve inventory when a cart item is added. These registrations are wired up through the \AddApplicationServices\ method, centralizing the service configuration for the warehouse command domain.

src/Services/Identity/Query/Application/DependencyInjection, src/Services/Warehouse/Command/Application/DependencyInjection · high confidence

The Account service now includes new domain entities for user profiles and addresses, introducing structured validation and data transfer capabilities. Profile entities now enforce email format, ensure first and last names are distinct, and require users to be over 18 if a birthdate is provided. Address entities distinguish between billing and shipping types, validating that core fields like city, country, and street are present, while ensuring street numbers are positive and complements do not exceed 80 characters.

src/Services/Account/Command/Domain/Entities · high confidence

The Catalog Command service introduces a new architectural foundation for entities and message handling. Domain entities now inherit from a generic base class that enforces validation via a specified FluentValidation validator, ensuring business rules are checked before state changes. Additionally, the message bus infrastructure now includes two new MassTransit pipe filters: a contract validator that checks incoming message schemas and routes validation failures to a dedicated error queue, and a business validator that handles validation exceptions thrown during processing, also routing them to a specific error queue for centralized error handling.

src/Services/Catalog/Command/Domain/Abstractions/Entities, src/Services/Catalog/Command/Infrastructure.MessageBus/Abstractions, src/Services/Catalog/Command/Infrastructure.MessageBus/PipeFilters · high confidence

The shopping cart command service now uses a new \AggregateRoot\ base class and \IAggregateRoot\ interface to manage domain events. This change introduces automatic versioning, a read-only collection of uncommitted events, and a standardized mechanism for applying events from history and raising new ones, ensuring consistent event-sourcing behavior across cart aggregates.

src/Services/ShoppingCart/Command/Domain/Abstractions/Aggregates · high confidence

The ShoppingCart command service now uses a new EventBusGateway class to handle event publishing. This implementation leverages MassTransit's IBus and IPublishEndpoint to support publishing single events, batches of events, and scheduled delayed events, replacing the previous infrastructure approach.

src/Services/ShoppingCart/Command/Infrastructure.MessageBus · high confidence

The Catalog Command service now uses a new \EventBusGateway\ implementation that leverages MassTransit's \IBus\ and \IPublishEndpoint\ to handle event publishing and scheduled publishing. This replaces the previous infrastructure with a standardized gateway interface (\IEventBusGateway\), enabling consistent event dispatching and delayed event scheduling for the catalog domain.

src/Services/Catalog/Command/Infrastructure.MessageBus · high confidence

The communication service now includes new message bus consumers to handle specific domain events. A new consumer triggers notification requests when a user registers, and another consumer sends notifications when a notification request is made. Additionally, a new event bus consumer retrieves project notification details when a notification is changed. These changes implement the underlying event handling logic for these communication flows.

src/Services/Communication/Command/Infrastructure.MessageBus/Consumers, src/Services/Communication/Query/Infrastructure.EventBus/Consumers · high confidence

The Order service now reacts to external domain events to drive order state changes. A new handler listens for the CartSubmitted summary event from the Shopping Cart service to automatically create a new Order aggregate, and another handler listens for the PaymentCompleted event from the Payment service to confirm existing orders. These interactors bridge the gap between upstream service events and the Order command model, ensuring orders are placed and confirmed in response to completed cart submissions and payments.

src/Services/Order/Command/Application/UseCases/Events · high confidence

The catalog query service now includes four new interactor classes that automatically update read-model projections in response to domain events. When a catalog is created, activated, deactivated, or has its title/description changed, the \ProjectCatalogGridItemWhenCatalogChangedInteractor\ updates the catalog grid view. Similarly, adding a catalog item triggers updates to the \CatalogItemCard\ and \CatalogItemDetails\ projections via their respective interactors, while adding, removing, or deleting a catalog item updates the \CatalogItemListItem\ projection. These changes ensure the query-side views stay consistent with catalog state changes.

src/Services/Catalog/Query/Application/UseCases/Events · high confidence

The query-side read model now automatically updates when account or address events occur. New interactor classes handle AccountCreated, AccountActivated, AccountDeactivated, AccountDeleted, BillingAddressAdded, and ShippingAddressAdded events, ensuring that the AccountDetails, BillingAddressListItem, and ShippingAddressListItem projections are kept in sync with domain changes.

src/Services/Account/Query/Application/UseCases/Events · high confidence

The Catalog service contracts have been migrated to a new architecture, introducing a Protobuf definition (Catalog.proto) that exposes gRPC endpoints for listing and retrieving catalog items, along with corresponding CQRS command, query, and domain event records. This change establishes the interface layer for catalog operations, including validation rules for commands and events, and defines the data projections used to serialize catalog data for the query side.

src/Contracts/Services/Catalog · high confidence

The warehouse command service now includes dedicated message bus consumers to handle specific inventory adjustments and external events. New consumers have been added for the CreateInventory, DecreaseInventoryAdjust, IncreaseInventoryAdjust, and ReceiveInventoryItem commands, enabling the system to process these updates via the message bus. Additionally, a CartItemAdded consumer has been introduced to react to shopping cart domain events by triggering inventory reservation logic.

src/Services/Warehouse/Command/Infrastructure.MessageBus/Consumers · high confidence

The Warehouse Command service now includes dedicated pipe filters to handle validation failures within the message bus pipeline. A new BusinessValidatorFilter intercepts ValidationExceptions and routes them to a specific business-error queue, while a ContractValidatorFilter validates incoming messages against FluentValidation rules and sends contract validation errors to a dedicated contract-errors queue. This change centralizes validation error handling, ensuring that both business rule violations and contract schema mismatches are logged and routed to appropriate error queues rather than failing silently or crashing the consumer.

src/Services/Warehouse/Command/Infrastructure.MessageBus/PipeFilters · high confidence

The query-side infrastructure now uses a new ProjectionDbContext and a generic ProjectionGateway to manage read-model data. The gateway enforces idempotency on upsert operations by checking and comparing a version field (UpdateFieldAsync, ReplaceInsertAsync, RebuildInsertAsync), ensuring that updates are only applied if the stored version is lower than the incoming one. It also provides standard query capabilities including retrieval by ID, filtered searches, paginated listing, and deletion.

src/Services/Identity/Query/Infrastructure.Projections, src/Services/Payment/Query/Infrastructure.Projections, src/Services/Warehouse/Query/Infrastructure.Projections · high confidence

The catalog query service now uses a new ProjectionGateway and ProjectionDbContext to manage read-side data. This change introduces a generic gateway that supports paginated listing, field-level updates with optimistic concurrency (version checks), and idempotent upserts that handle duplicate key conflicts gracefully. It replaces previous bulk upsert mechanisms with a more robust, version-aware approach for maintaining projection consistency.

src/Services/Catalog/Query/Infrastructure.Projections · high confidence

The Account Query service now uses a new \ProjectionDbContext\ and \ProjectionGateway\ to manage read-side data. The gateway introduces version-based optimistic concurrency control, ensuring idempotent updates by comparing the \version\ field before applying changes. It also handles duplicate key errors gracefully during upserts, providing a more robust foundation for projecting events to the query model.

src/Services/Account/Query/Infrastructure.Projections · high confidence

The Order command stack now configures its message bus infrastructure with specific behaviors for event handling and message correlation. The dependency injection setup registers RabbitMQ endpoints for order-related events (such as cart submission and payment completion) using kebab-case naming conventions. Additionally, a pipe specification ensures that the correlation ID is automatically set to the initiator ID when publishing events, improving traceability across distributed operations.

src/Services/Order/Command/Infrastructure.MessageBus/DependencyInjection/Extensions, src/Services/Warehouse/Command/Infrastructure.MessageBus/DependencyInjection · high confidence

The Payment aggregate in the command domain has been refactored to replace primitive numeric types with a dedicated Money value object for handling payment amounts. This change introduces a new Payment aggregate class and its corresponding validator, establishing a stronger domain model where monetary values are explicitly typed rather than represented as simple decimals or integers. The aggregate now manages payment status, billing address, and multiple payment methods, utilizing the Money object to track the total amount and calculate amounts due based on authorized payment methods.

src/Services/Payment/Command/Domain/Aggregates · high confidence

The Payment Command Application layer has been restructured to use a new architectural style. This introduces a unified \IInteractor\ interface for handling commands and events, replacing previous patterns. It adds a new \ApplicationService\ that coordinates with \IEventStoreGateway\ and \IEventBusGateway\ for event sourcing, and implements a \PaymentGateway\ using a chain-of-responsibility pattern to route authorization, cancellation, and refund operations through specific payment service implementations (CreditCard, DebitCard, PayPal).

src/Services/Payment/Command/Application · high confidence

The Payment service's command infrastructure has been replaced with a new MassTransit implementation. This introduces a generic \Consumer\<T\>\ base class that delegates message handling to application interactors, alongside specific consumers for payment commands and domain events (such as \OrderPlaced\ and \PaymentRequested\). The migration includes a new dependency injection setup that configures RabbitMQ connections with kebab-case endpoint naming, JSON serialization with custom converters, and retry policies. Additionally, the system now features pipe filters for contract and business validation, as well as comprehensive logging observers for publish, send, receive, and consume operations, ensuring consistent observability and error handling across the message bus.

src/Services/Payment/Command/Infrastructure.MessageBus · high confidence

A new Product value object has been added to the domain layer, defined as a record with properties for description, name, brand, category, unit, and SKU. It includes implicit conversion operators to and from the Dto.Product type, allowing seamless interoperability between the domain model and data transfer objects. Additionally, a corresponding ProductValidator has been introduced to support validation of these product instances.

src/Services/Catalog/Command/Domain/ValueObjects/Products · high confidence

A new interactor has been added to the query-side event handling pipeline to maintain the project notification details projection. When a NotificationRequested domain event occurs, this component now creates or replaces the corresponding NotificationDetails projection record, ensuring the read model is updated with the notification ID and version.

src/Services/Communication/Query/Application/UseCases/Events · high confidence

The Catalog Command application layer has been refactored to use a new architectural style, introducing four new interfaces in the Abstractions namespace. IEventBusGateway and IEventStoreGateway replace previous mechanisms for publishing events and managing aggregate persistence, providing explicit methods for publishing, scheduling, appending, and loading aggregates. IInteractor standardizes command handling via a generic InteractAsync method, while IUnitOfWork defines a transactional execution boundary. These changes shift how the application interacts with infrastructure and manages unit-of-work semantics.

src/Services/Catalog/Command/Application/Abstractions · high confidence

The Warehouse command application layer has been refactored to a new architectural style, introducing four new interface contracts in the Abstractions directory. IInteractor\<TMessage\> standardizes how commands (messages) are processed, while IEventBusGateway and IEventStoreGateway define the boundaries for publishing events and loading/appending aggregate state. Additionally, IUnitOfWork provides a mechanism to wrap operations in a transactional scope. These interfaces replace previous implementations, shifting the application layer's dependency model toward these specific gateway and interaction contracts.

src/Services/Warehouse/Command/Application/Abstractions · high confidence

The application layer's abstraction boundaries for the Communication service have been restructured. New interfaces define specific gateways for email, event bus, and event store interactions, alongside a generic notification gateway. A concrete NotificationService has been introduced that utilizes a new ILazy abstraction to resolve specific notification gateways (email, SMS, push mobile, push web) and dispatches notifications based on method options. Additionally, core infrastructure interfaces for unit of work and message interaction (IInteractor) have been added to support the new design.

src/Services/Communication/Command/Application/Abstractions · high confidence

The Catalog Query service's event bus infrastructure has been restructured to replace automatic endpoint configuration with explicit, fine-grained bindings for specific catalog domain events. New consumer classes (such as \ProjectCatalogGridItemWhenCatalogChangedConsumer\) now handle specific events like \CatalogCreated\ or \CatalogItemAdded\ by delegating to corresponding interactors, ensuring precise routing. The configuration enforces kebab-case naming for queues and exchanges via \KebabCaseEntityNameFormatter\ and \KebabCaseEndpointNameFormatter\, and introduces a \ContractValidatorFilter\ to validate incoming messages before processing. Additionally, comprehensive logging observers (\LoggingReceiveObserver\, \LoggingConsumeObserver\) have been added to track message lifecycle, duration, and faults, while dependency injection is centralized in \ServiceCollectionExtensions\ to configure MassTransit with RabbitMQ, retry policies, and JSON serialization settings.

src/Services/Catalog/Query/Infrastructure.EventBus · high confidence

The Warehouse command service's message bus implementation has been updated to a new architectural style. A generic abstract Consumer base class is now provided to simplify message handling by delegating consumption to an IInteractor, and a new EventBusGateway has been introduced to standardize event publishing and scheduled publishing via MassTransit.

src/Services/Warehouse/Command/Infrastructure.MessageBus · high confidence

The Account service's message bus infrastructure has been restructured to support a new design pattern. A new abstract Consumer base class now handles message consumption by delegating to an IInteractor, simplifying the implementation of specific message handlers. Additionally, a new EventBusGateway has been introduced to manage event publishing and scheduled publishing via MassTransit, replacing previous mechanisms. These changes align with the broader migration of the Account service to a new architectural style.

src/Services/Account/Command/Infrastructure.MessageBus · medium confidence

The payment query application layer has been restructured to introduce generic interaction interfaces (IInteractor, IPagedInteractor) for handling queries and events, alongside a new IProjectionGateway interface that defines methods for finding, listing, and updating projections. These abstractions are wired into the service collection via new extension methods (AddEventInteractors, AddQueryInteractors), replacing previous patterns with a more explicit, generic-based approach for projecting payment details and handling payment-related events.

src/Services/Payment/Query/Application · high confidence

The SmtpOptions class has been refactored into an immutable record with required properties, ensuring that Host, Port, Username, and Password must be explicitly provided during configuration. This change introduces compile-time and runtime validation via DataAnnotations (Required, MinLength, EmailAddress), preventing the service from starting with incomplete or invalid SMTP settings.

src/Services/Communication/Command/Infrastructure.SMTP/DependencyInjection/Options · high confidence

The ShoppingCart command application layer now uses a new set of abstractions to define its core interactions and infrastructure contracts. This includes a generic IInteractor interface for processing messages, an IUnitOfWork interface for managing transactional operations, and specific gateway interfaces (IEventBusGateway and IEventStoreGateway) that define how the service publishes events and persists aggregate state. These changes replace the previous abstraction design, aligning the shopping cart's command handling with the updated architectural style.

src/Services/ShoppingCart/Command/Application/Abstractions · high confidence

The shopping cart command-side domain model has been restructured to support a new architectural design. A new abstract base entity class now enforces generic validation via FluentValidation for all domain entities, while a corresponding interface defines the core identity and soft-delete contract. Product data is now represented as a value object with implicit conversions to and from DTOs, accompanied by a dedicated validator. Additionally, a generic message consumer base class has been introduced to standardize how incoming messages are routed to application interactors via MassTransit.

src/Services/ShoppingCart/Command/Domain/Abstractions/Entities, src/Services/ShoppingCart/Command/Domain/ValueObjects/Products, src/Services/ShoppingCart/Command/Infrastructure.MessageBus/Abstractions · medium confidence

The command handlers for the shopping cart service have been refactored to use a new interactor-based design. Each command (such as adding items, changing quantities, checking out, or managing payment methods) is now handled by a dedicated interactor class that loads the ShoppingCart aggregate, applies the command, and appends the resulting events via the ApplicationService. This change standardizes how cart operations are processed and ensures consistent event sourcing behavior across all cart modifications.

src/Services/ShoppingCart/Command/Application/UseCases/Commands · high confidence

The ShoppingCart aggregate in the Command service has been rewritten to use an event-sourcing pattern, replacing previous state management with explicit command handlers and domain events. The new model tracks cart lifecycle through a CartStatus enum (Empty, Active, Abandoned, CheckedOut) and manages items and payment methods (CreditCard, DebitCard, PayPal) by raising events such as CartItemAdded, CartItemIncreased, and CreditCardAdded. A new ShoppingCartValidator enforces business rules, ensuring totals are positive when items exist and validating addresses and payment methods. This change shifts the cart's behavior to be driven by immutable events, improving auditability and consistency for operations like adding items, changing quantities, and checking out.

src/Services/ShoppingCart/Command/Domain/Aggregates · high confidence

The shopping cart's command-side event store has been restructured to use a dedicated \EventStoreDbContext\ that persists \StoreEvent\ and \Snapshot\ entities via Entity Framework Core. This change introduces specific EF Core configurations for these entities and adds \AggregateConverter\ and \EventConverter\ classes to serialize domain aggregates and events to JSON using \Newtonsoft.Json\ with \TypeNameHandling.Auto\ and custom date converters. For users, this represents an internal infrastructure update to the persistence mechanism, likely improving how domain events and snapshots are stored and retrieved, without changing the external API or user-facing behavior of the shopping cart.

src/Services/ShoppingCart/Command/Infrastructure.EventStore/Contexts · high confidence

The shopping cart command service now configures its MassTransit/RabbitMQ infrastructure to use kebab-case formatting for endpoint and entity names, ensuring consistent queue naming conventions. Additionally, the message bus is configured to explicitly map the initiator ID to the correlation ID for published events, improving traceability across distributed operations. The setup also includes specific JSON converters for date handling and registers event receive endpoints for cart checkout and projection rebuild events.

src/Services/ShoppingCart/Command/Infrastructure.MessageBus/DependencyInjection/Extensions · high confidence

The shopping cart query layer has been refactored to use new interactor classes that retrieve data via a projection gateway. Specific handlers for retrieving cart details, item details, customer cart details, payment method details, and listing cart items or payment methods now delegate to the projection gateway, with list operations supporting pagination. This change updates how the application fetches shopping cart data, moving from previous implementations to this new projection-based approach.

src/Services/ShoppingCart/Query/Application/UseCases/Queries · high confidence

The shopping cart query service now uses MassTransit to process domain events, introducing dedicated consumers for cart details, item lists, and payment methods. This change adds contract validation via FluentValidation filters, structured logging through consume and receive observers, and configurable retry policies. Queue names are standardized to kebab-case, and the system supports both RabbitMQ and in-memory transports for testing.

src/Services/ShoppingCart/Query/Infrastructure.EventBus · high confidence

The shopping cart query side has been refactored to use a new projection infrastructure that ensures idempotency and consistency. A dedicated \ProjectionDbContext\ connects to MongoDB, while the \ProjectionGateway\ handles all read operations. Crucially, write operations (updates and inserts) now check and enforce a version number (\projection.Version \< version\), preventing stale data overwrites and ensuring that repeated events do not corrupt the read model. This replaces previous upsert mechanisms with a safer, version-controlled approach.

src/Services/ShoppingCart/Query/Infrastructure.Projections · high confidence

The query-side read model for the shopping cart is now updated via dedicated event interactor classes that process domain events to keep projections in sync. ProjectCartDetailsWhenCartChangedInteractor maintains the main ShoppingCartDetails projection, handling creation, total updates on item changes, status updates on checkout, deletion on discard, and full rebuilds via CartProjectionRebuilt. ProjectCartItemListItemWhenCartChangedInteractor manages individual item records, inserting on addition, updating quantity on increase/decrease, and deleting on removal or cart discard. ProjectPaymentMethodListItemWhenCartChangedInteractor tracks payment methods, inserting records for credit card, debit card, and PayPal additions, and deleting them when the cart is discarded. These interactors use a projection gateway to perform replace/insert, field updates, and deletes, ensuring the query-side data reflects the latest cart state.

src/Services/ShoppingCart/Query/Application/UseCases/Events · high confidence

The ShoppingCart service contract layer has been reorganized into a new design, introducing explicit command, domain event, notification, and summary event records for operations such as creating carts, adding/removing items, managing payment methods (CreditCard, DebitCard, PayPal), and handling addresses. These contracts are now paired with a Protobuf service definition (ShoppingCart.proto) that exposes gRPC-style RPCs for retrieving cart details, customer cart details, item details, payment method details, and listing items and payment methods with paging. Implicit conversion operators have been added to map internal projection records (ShoppingCartDetails, ShoppingCartItemDetails, PaymentMethodDetails, etc.) to their Protobuf counterparts and to deserialize Protobuf requests into internal query records. Validation scaffolding using FluentValidation has been added for key commands, with CreateCart and RemoveCartItem validators enforcing non-empty identifiers, while others remain as empty placeholders.

src/Contracts/Services/ShoppingCart · high confidence

The Identity service's event store abstraction has been refactored to remove generic type parameters, replacing the previous generic repository pattern with a concrete \IEventStoreRepository\ interface. This interface now handles \StoreEvent\ and \Snapshot\ records directly, simplifying how domain events and aggregate snapshots are appended and retrieved for identity-related aggregates.

src/Services/Identity/Command/Domain/Abstractions/EventStore · high confidence

The catalog command consumers (Activate, AddCatalogItem, ChangeCatalogDescription, ChangeCatalogTitle, Create, Deactivate, Delete, and RemoveCatalogItem) have been refactored to use a simplified design. Each consumer now directly inherits from a base Consumer class and delegates execution to a single IInteractor, removing previous complexity in how these message bus handlers processed catalog commands.

src/Services/Catalog/Command/Infrastructure.MessageBus/Consumers · high confidence

The system now uses a consistent exception class, AggregateNotFoundException, across all command-side services (Account, Catalog, Communication, Identity, Order, ShoppingCart, and Warehouse). This change ensures that when an aggregate is not found in the event store, the error message explicitly includes both the aggregate type name and its ID, providing clearer diagnostic information for debugging and error handling.

(repo-wide) · high confidence

The catalog query layer now uses a unified interactor pattern where list operations implement IPagedInteractor to return paginated results via the projection gateway, while detail retrieval uses the standard IInteractor interface. This change introduces dedicated interactors for listing catalog items in card, list, and grid views, ensuring consistent handling of paging parameters and projection lookups across the catalog service.

src/Services/Catalog/Query/Application/UseCases/Queries · high confidence

The ListInventoriesGridItemInteractor and ListInventoryItemsListItemsInteractor in the Warehouse Query service have been refactored to implement the IPagedInteractor interface. This change standardizes how these specific inventory listing queries are executed, delegating the actual data retrieval to the projection gateway while ensuring consistent paging behavior for the user-facing inventory grid and list views.

src/Services/Warehouse/Query/Application/UseCases/Queries · high confidence

The payment query service now uses new interactor classes to keep the read model in sync with domain events. The \ProjectPaymentMethodDetailsWhenChangedInteractor\ handles authorization, denial, cancellation, and refund events by updating the payment method status, explicitly passing the event version to ensure idempotency. The \ProjectPaymentWhenChangedInteractor\ manages payment status updates for cancellation events and creates new payment detail records for \PaymentRequested\ events, also incorporating the event version into the stored projection.

src/Services/Payment/Query/Application/UseCases/Events · high confidence

The Warehouse Query service now uses a new event bus implementation based on MassTransit with RabbitMQ. This change introduces a standardized consumer abstraction, specific consumers for inventory-related domain events (such as inventory creation and adjustments), and dependency injection extensions to configure the bus. The new setup includes kebab-case endpoint naming, configurable retry policies, JSON serialization with custom converters, and detailed logging/observation for message consumption and faults, replacing the previous infrastructure.

src/Services/Warehouse/Query/Infrastructure.EventBus · high confidence

The Warehouse command domain has been refactored to a new Event Sourcing style, introducing a generic \AggregateRoot\ base class that manages versioning, domain event raising, and history loading. The \Inventory\ aggregate now implements this pattern, handling commands like creating inventory, receiving items, and reserving stock by emitting domain events. Supporting infrastructure includes new abstractions for the Event Store (\IEventStoreRepository\, \StoreEvent\, \Snapshot\), base \Entity\ classes with validation, and specific domain models for inventory items, adjustments, and product value objects.

src/Services/Warehouse/Command/Domain · high confidence

The Warehouse service now defines a comprehensive set of internal contracts including commands for inventory operations (receiving, adjusting, reserving, creating), domain events that include a version number for optimistic concurrency, and queries for listing inventory grids and items. These contracts are supported by a new gRPC service definition in Warehouse.proto and projection records that map internal models to protobuf messages, establishing the interface layer for the warehouse's command and query side.

src/Contracts/Services/Warehouse · high confidence

Added new test files to verify the Shopping Cart domain logic, including unit tests for cart creation, item addition, quantity changes, and address updates, as well as integration tests for the WebAPI and Query Stack to ensure correct event projection and service client behavior.

test · high confidence

The solution introduces a new layered architecture for services (Account, Catalog, Communication, Identity, Order, Payment, ShoppingCart), splitting each into Command and Query stacks with dedicated Application, Domain, and Infrastructure projects. This change adds numerous .csproj files defining dependencies for MassTransit, RabbitMQ, Quartz, EF Core, gRPC, Serilog, and OpenTelemetry, establishing the build-time contract for the new microservice design.

(dependencies) · high confidence

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

• First survey — no prior run to compare against. CAI 43.

• Code Health 93
• Architecture 82
• Maturity 54
• Readiness 62
• Security 25
• Domain Modelling 71
• Accessibility 53
• Performance 73

• 300 commits — 299 feature/other, 1 fixes

• (repo) — 119 commits
• src/Services — 80 commits
• (root) — 70 commits
• src/Contracts — 12 commits
• test/ShoppingCartQueryStackIntegrationTests — 6 commits
• test/ShoppingCartTests — 5 commits
• src/Web — 4 commits
• .github/workflows — 2 commits
• .assets/img — 1 commit
• .github/CleanWorkflows.ps1 — 1 commit

• fix: Merge pull request #553 from AntonioFalcaoJr/fix/dto-to-money-conversion
• change: Adding CleanWorkflows.ps1 script
• change: Adding Mathias Verraes reference
• change: Adding Money DTO and Cleaning
• change: Adding connection name and fixing correlation id
• change: Adding soft delete
• change: Adding summary event
• change: Adjust
• change: Adjust
• change: Adjust
• change: Adjusting
• change: Adjusting
• change: Adjusting
• change: Adjusting
• change: Adjusting Status and nullability in types initialization
• change: Adjusting URL on staging environment
• change: Adjusting compose for windows environment
• change: Adjusting composes
• change: Adjusting contracts
• change: Adjusting migrations
• …and 280 more

• 1 HTTP endpoints (baseline)

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

AntonioFalcaoJr/EventualShop 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.