EquinoxProject: a .NET 9 reference implementation for Clean Architecture, CQRS and Event Sourcing

What EquinoxProject actually is, and who it is for

EquinoxProject is an open-source .NET application whose stated goal is to implement the most common technologies used in ASP.NET development and share what the author considers good practice. It is not a library you add to a project and not a framework with an API surface. It is a complete solution you clone and read.

The intended audience is developers who already know C# and ASP.NET but have not assembled a layered application end to end. The README describes the result as a full architecture with responsibility separation, SOLID and Clean Code, plus Domain Driven Design, domain events, domain notifications, domain validations, CQRS with immediate consistency, event sourcing, unit of work and the repository pattern. That list is the syllabus.

The disclaimer matters more than the feature list. The README states the project is not intended to be a definitive solution, warns about using it in production, and notes that you may not need many of the implementations included, asking readers to avoid over engineering. Treat that as the author's own scope statement rather than a formality. The pull-request policy reinforces it: the README asks contributors not to submit PRs for extra features because new features are planned by the maintainer.

How the layers and the request flow fit together

The repository separates src/ and tests/ at the top level, with a solution file, a sql/ folder, a docs/ folder, and configuration files including .editorconfig and AGENTS.md. The architecture section of the README names the patterns rather than the projects, so the layer boundaries have to be read from the solution itself.

The flow the README describes is a web application with two entry points, ASP.NET MVC Core and a WebApi Core, both backed by ASP.NET Identity Core for users and JWT bearer authentication for the API. Requests move through command and query handling, with domain events and domain notifications raised as the domain model changes, and validation handled by FluentValidation rather than by attributes on view models. Persistence goes through Entity Framework Core 9.0 behind a unit of work and repositories.

Two changes in v1.10 matter for anyone comparing this code to older tutorials. MediatR was replaced by NetDevPack.SimpleMediator, described in the release notes as lighter and native CQRS handling, and AutoMapper was removed in favour of custom mapping extensions. If you are following a blog post written before April 2025, the mediator interfaces and the mapping calls will not match what is in master. The README's technology list confirms both removals.

Installing EquinoxProject and running it for the first time

The README's setup instructions are deliberately thin. It says you need the latest version of Visual Studio and the latest .NET Core SDK, tells you to check that you have the runtime version installed, and points to https://dot.net/core for the SDK and tools. It also states the project can run in Visual Studio Code on Windows, Linux or macOS, and links the Microsoft .NET download guide for environment setup.

There is no dotnet CLI install command in the README because this is a solution, not a package. The practical path is to open Equinox.sln in Visual Studio, or open the folder in Visual Studio Code, and build it there. The README does not give a build command, so the first real check is simply that the solution compiles against .NET 9 on your machine. A machine with only an older SDK will fail here, which is what the README's warning about the runtime version is pointing at.

The v1.10 release notes add the detail that makes a first run easy: built-in SQLite support with automatic EF Core migrations, described as just run and go with no setup required. That means you do not need to provision SQL Server before seeing the application work. The WebApi project exposes Swagger UI with JWT support, so the expected result is a browser page listing the endpoints where you can authenticate and issue calls. The README does not document a launch URL or port, so read the launch settings in the WebApi project if the default does not open. A sql/ folder exists at the repository root for anyone who wants to point the application at a different database.

The over-engineering warning is a real limitation, not a disclaimer

The most useful sentence in the README is the one telling readers they may not need many of the implementations included. EquinoxProject layers domain events, domain notifications, CQRS handlers, a unit of work and repositories on top of a sample application. Each of those is a place where a bug can hide and where a new developer has to learn an indirection before changing a line of business logic.

For a small CRUD application, that cost is not recovered. A single controller with EF Core and a service class will be faster to write, faster to review and easier to hand over. The patterns in EquinoxProject pay off when you have genuinely complex domain rules, or when you need an audit trail that event sourcing provides. If your domain is mostly data entry, the architecture is overhead you will maintain forever.

There is a second, sharper limitation. The README states the project is not intended to be a definitive solution and warns about production use. Nothing in the README describes a migration path, a rollback strategy, or operational guidance for the event store. If you base a production system on this code, you are adopting an architecture sample as a foundation, and the author has told you not to. Use it to learn the shape of the architecture, then build your own foundation.

EquinoxProject compared with a plain Onion Architecture sample

The related searches around this project cluster on onion architecture and clean architecture repositories, and the comparison is worth making precisely because the two answer different questions.

A typical onion architecture sample exists to demonstrate dependency direction: domain at the centre, application services around it, infrastructure and UI on the outside, with dependencies pointing inward. That is one idea, demonstrated with minimal ceremony. EquinoxProject demonstrates that idea and then adds CQRS, domain events, event sourcing, notifications, a unit of work and identity on top. The dependency rule is present, but it is not the only thing competing for your attention.

If your goal is to explain layer boundaries to a team, a smaller onion sample will do it in an afternoon. If your goal is to see how CQRS handlers, domain events and validation coexist in one ASP.NET 9 solution that actually builds and runs, EquinoxProject is the more complete example, and the v1.10 architecture tests using NetArchTest.Rules give you a way to check that the boundaries are enforced rather than merely intended. That test project is the part most comparable samples lack.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-04-14. Releases have followed the .NET release cycle closely: v1.8 on .NET 6 in March 2022, v1.9 on .NET 8 in July 2024, and v1.10 on .NET 9 in April 2025. That cadence tells you what maintenance looks like in practice. A version bump here is not a dependency patch; it is a migration, and v1.9 and v1.10 both involved refactoring the web and API configuration and replacing core libraries.

If you fork this project, budget for that pattern. Every .NET major release has historically meant revisiting the whole solution, and the v1.10 changes show the maintainer is willing to remove dependencies that no longer earn their place. Code you write against NetDevPack.SimpleMediator or the custom mapping extensions today will need review when the next version lands, because the project has already demonstrated that it will swap those pieces out.

The licence is MIT, stated in the README and in the LICENSE file at the repository root. MIT is permissive and imposes few conditions, but the README's own disclaimer about production use is a technical judgement, not a legal one, and no licence removes it. Read the LICENSE file for the exact terms rather than relying on the badge.

What to check before you copy a pattern out of it

The repository ships an AGENTS.md file and a docs/ folder alongside the source. Both are worth reading before you assume the README is the whole story, because the README is written as an introduction and stops short of explaining how the pieces connect.

The highest-value check is the tests/ directory. The v1.10 release notes mention architecture tests built with NetArchTest.Rules, which is unusual for a sample project and is the closest thing here to an executable specification of the architecture. Running those tests tells you which dependency rules the project actually enforces, as opposed to which ones the README claims. If you are adopting the layering for your own solution, copy the test project before you copy the folder structure.

The second check is the sql/ folder and the EF Core migration setup. The default path is SQLite with automatic migrations, which is what makes the sample frictionless, but it is also the assumption most likely to differ from your environment. Confirm how migrations are applied before you plan a deployment, because the README does not document that step.

Editorial conclusion

Use EquinoxProject if you are learning how Clean Architecture, DDD and CQRS fit together in a real ASP.NET 9 solution and want a codebase you can step through layer by layer. Do not use it as a production starting point: the README states it is not a definitive solution and warns about production use and over engineering. Before adopting any pattern from it, open the architecture tests under tests/ and confirm which layers they actually enforce, then check the sql/ folder and the EF Core migration setup to see what database assumptions the sample makes.

Frequently asked questions

Official sources

1. EduardoPires/EquinoxProject on GitHub
2. License: MIT
3. Project website
4. README
5. Releases