event-driven-dotnet/EventDriven.ReferenceArchitecture

This system is a .NET 8-based reference architecture for building event-driven microservices using Domain-Driven Design and CQRS. It provides a complete, runnable example of loosely coupled services (Customer and Order) that communicate via a Dapr-backed event bus and persist data in MongoDB. The project includes full test coverage with unit and acceptance tests to validate the architecture's behavior.

The reference architecture now includes fully implemented Customer and Order microservices. Each service exposes REST APIs for creating, updating, and removing entities, as well as querying them. The implementation uses a CQRS pattern with MediatR, featuring command and query handlers, DTOs, and domain models. The services are configured to use MongoDB for persistence and Dapr for event bus capabilities, with logging behaviors and dependency injection registrations included.

reference-architecture · high confidence

The repository now includes a complete reference architecture for building loosely coupled, event-driven microservices using Domain-Driven Design (DDD) and Command Query Responsibility Segregation (CQRS) with Dapr for publish-subscribe messaging. The solution provides a step-by-step Development Guide, a README with prerequisites and usage instructions, and a .NET 8.0 SDK configuration. The architecture features Customer and Order services that communicate via an event bus abstraction, with separate controllers for read and write operations. The project also includes unit tests using xUnit and Moq, as well as acceptance tests using SpecFlow. Additionally, Dapr components and configuration files are provided for local development, and the repository is licensed under the MIT License.

(repo-wide) · high confidence

Added SpecFlow-based acceptance tests for Customer, Order, and Pub/Sub services; Added unit and integration tests for the Order service; Added unit tests for CustomerService domain and controllers.

The reference architecture has been upgraded to .NET 8, enabling access to the latest performance and security improvements. Key packages have been updated to their latest stable versions, including Aspire (8.2), EventDriven.CQRS.Abstractions (2.1.0), EventDriven.CQRS.Extensions (2.0.0), and EventDriven.EventBus.Dapr (1.6.0). Additionally, test projects now use xUnit 2.9.0 and SpecFlow 3.9.74, ensuring compatibility with the new framework version.

(dependencies) · high confidence

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

• CAI 47 → 47 (-0.0)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 83 → 81 (-1.3)
• Architecture 89 → 89 (+0.0)
• Maturity 64 → 64 (+0.0)
• Readiness 41 → 39 (-1.8)
• Security 44 → 44 (+0.0)
• Domain Modelling 45 → 51 (+6.2)
• Event-Driven 77 → 77 (+0.0)

• Bounded contexts not declared
• Build did not complete in the analyzer
• Coverage not measured — analyzer environment
• No exposed public API
• XML-doc coverage: ReferenceArchitecture.AppHost (reference-architecture/ReferenceArchitecture.AppHost/ReferenceArchitecture.AppHost.csproj)
• early-stage repository — too few commits for a meaningful bus factor
• early-stage repository — too little history to judge knowledge freshness
• redundant comment (reference-architecture/CustomerService/Program.cs)

• CommentedOutCode (reference-architecture/ReferenceArchitecture.ServiceDefaults/Extensions.cs)
• CoverageExclusion (reference-architecture/CustomerService/Repositories/CustomerRepository.cs)
• CoverageExclusion (reference-architecture/OrderService/Repositories/OrderRepository.cs)
• Documentation: no architecture or design documentation (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (5 lines × 4) (reference-architecture/CustomerService/DTO/Read/CustomerView.cs)
• Duplicated block (6 lines × 2) (reference-architecture/CustomerService/DTO/Read/CustomerView.cs)
• Duplicated block (7 lines × 2) (reference-architecture/CustomerService/DTO/Write/Address.cs)
• Inconsistent parameter naming for Command objects. While 'command' is used consistently for the command objects themselves, the parameter name 'command' is generic. However, the more significant inconsistency is the mix of 'command' (lowercase) and 'Command' (uppercase, as seen in OrderService.Domain.OrderAggregate.Commands.UpdateOrder command vs potentially others if they were named differently, but here they are consistent as 'command'). Wait, looking closer at the list: OrderService.Domain.OrderAggregate.Commands.UpdateOrder command and OrderService.Domain.OrderAggregate.Commands.CreateOrder command are consistent. The inconsistency is actually between OrderService.Domain.OrderAggregate.Order Entity (the entity) and OrderService.Domain.OrderAggregate.Commands.UpdateOrder command (the command). The parameter 'Entity' is a generic noun, while 'command' is also a generic noun but refers to the command. The real issue is OrderService.Domain.OrderAggregate.Order Entity vs OrderService.Domain.OrderAggregate.Order e. 'Entity' and 'e' are inconsistent for the same type.
• Inconsistent parameter naming for the Order entity. One method uses the abbreviation 'e' while another uses the full noun 'Entity' for the same type OrderService.Domain.OrderAggregate.Order. This creates confusion about whether 'e' refers to the entity or something else, and 'Entity' is a generic term that should be replaced with the specific type name 'order' for clarity.
• Inconsistent parameter naming for the Order entity. One parameter is named 'Entity' (capitalized, generic noun), while others in the same aggregate context use the specific type name 'command' or 'order' (lowercase, specific noun). Specifically, OrderService.Domain.OrderAggregate.Order Entity uses 'Entity' whereas OrderService.Domain.OrderAggregate.Commands.UpdateOrder command uses 'command'. In the context of the Order aggregate, the parameter representing the order itself should be consistently named (e.g., 'order' or 'entity'), but mixing 'Entity' with 'command' (which refers to the command object, not the entity) or inconsistent casing is confusing. More critically, looking at OrderService.Domain.OrderAggregate.Order e vs OrderService.Domain.OrderAggregate.Order Entity, the variable names 'e' and 'Entity' are inconsistent for the same concept.
• Low coverage: reference-architecture/Common/Behaviors/LoggingBehavior.cs (reference-architecture/Common/Behaviors/LoggingBehavior.cs)
• No test project references ReferenceArchitecture.AppHost (reference-architecture/ReferenceArchitecture.AppHost/ReferenceArchitecture.AppHost.csproj)

• Unchanged — 8 HTTP endpoints

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

event-driven-dotnet/EventDriven.ReferenceArchitecture 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.