# rafaelfgx/Architecture: a .NET 10 and Angular 22 reference solution built on Clean Architecture

> The repository is a runnable template rather than a library: a Web, Application, Domain, Model and Database split with a Mediator-based request flow. It is aimed at teams who want a working starting point for feature-segregated .NET services, and its value depends on whether that opinionated layout matches your own.

**rafaelfgx/Architecture** — .NET 10, Angular 22, Clean Architecture, Clean Code, SOLID, KISS, DRY, Mediator Pattern, Folder-by-Feature Structure

- Repository: https://github.com/rafaelfgx/Architecture
- Stars: 3,277 · Forks: 803
- Language: C#
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/rafaelfgx-architecture

## What rafaelfgx/Architecture actually is, and who it is for

This is a solution template. The README describes principles and patterns (Clean Architecture, Clean Code, SOLID, KISS, DRY, Mediator Pattern, Result Pattern, Folder-by-Feature Structure) and then documents the layers that implement them. There is no published package to add to an existing project: the packages listed in the README point at a separate repository, rafaelfgx/DotNetCore, and a NuGet profile. The thing you clone is the whole application, backend and frontend together.

That makes the audience fairly narrow. It suits a team starting a new ASP.NET Core service that wants a request pipeline, validation, logging and a database layer already arranged, and that accepts the author's division of responsibilities. It is a poor fit for someone who wants to retrofit a mediator into an existing codebase, because the layout is the product. The README's stated benefits are architectural rather than measurable: avoid cyclical references, avoid unnecessary dependency injection, segregate by feature instead of technical type. Those are claims about structure, and the repository is the evidence for them, not any benchmark.

## The layer contract: where business rules are allowed to live

The README is unusually explicit about which layer may contain what, and that is the most useful part of the project. Web holds the frontend and the backend; the backend Controller has no logic, business rules or dependencies other than mediator. Application is described as flow control with only business flow, not business rules. Domain holds the business rules and has no references to any other layer. Model is data transfer objects. Database handles persistence through a context, entity configurations and repositories.

The Application layer is where the design gets opinionated. A Request carries properties, a Request Validator holds the validation rules, a Response carries the result, and a Handler processes the request and returns the response. The README says the handler calls factories, repositories, unit of work, services or mediator, but has no business rules itself. A Factory creates complex objects so that changes to the object surface at compile time rather than runtime.

Domain is the strictest layer. It defines aggregates as consistency boundaries around one or more entities, with one entity as the root and the rest as children. Entities have identity, and the README states that changing properties is only allowed through internal business methods, not through direct property access. Value objects have no identity, are immutable, and must be replaced rather than mutated; their methods may encapsulate domain logic but must have no side effects on state. Domain services are stateless and exist only for operations that do not belong to an entity or value object. If you disagree with any of these boundaries, you are editing the template rather than configuring it.

## Running it: docker compose, then dotnet run

The README offers four paths: command line, Visual Studio Code, Visual Studio and Docker. The Docker path is the shortest because it brings its own database. The repository root contains docker-compose.yaml, which defines a web service built from the repository context and a database service using the mcr.microsoft.com/mssql/server image. Running the documented command starts both.

```bash
docker compose up --detach --build --force-recreate --remove-orphans
```

After the containers start, the README says to open http://localhost:8090. The compose file maps port 8090 on the host to port 8080 in the container, and maps 1433 for SQL Server. The web service waits on the database service and passes its connection string through the ConnectionStrings__Context environment variable, pointing at the host architecture_database with the sa user. Logs are written under /app/logs/ through a Serilog path setting.

If you prefer to run the pieces yourself, the command-line route needs the .NET SDK, SQL Server, Node and the Angular CLI. The README gives three steps: install the frontend dependencies, then run the backend from the source/Web directory, then open the same URL.

```bash
cd source/Web/Frontend
npm run restore
cd ..
dotnet run
```

The Visual Studio path differs only in the entry point: open source/Architecture.sln, set Architecture.Web as the startup project, and press F5. In Visual Studio Code you open the source directory and press F5 with the C# extension installed. In every case the frontend dependencies are installed first, from source/Web/Frontend.

## Two secrets sit in docker-compose.yaml in plain text

The compose file hardcodes a SigningKey value and an SA_PASSWORD value of P4ssW0rd! for the SQL Server container. This is normal for a template that has to start on a fresh machine, and it is also the first thing to change. Anything deployed with those values has a known signing key and a known database password. The README does not discuss secret management, environment-specific overrides, or how the SigningKey is consumed; the compose file is the only place the value appears in the repository.

The database is a second constraint. Every documented run path requires SQL Server, either the container image or an instance you provide. There is no SQLite or in-memory option in the README. That is a real cost for someone who wants to evaluate the architecture on a laptop without a container runtime, and it makes the project heavier than a pure source-reading exercise.

## Where the template stops being helpful

There are no releases. The repository has a build workflow badge and a .github directory, but the README documents no versioning scheme, no changelog and no upgrade path. If you fork it, you are not tracking a library's releases; you are tracking a repository's commits, and you will be resolving differences by hand. That is the central maintenance fact about this project.

The frontend is Angular, and the README says the backend's only dependency in the controller is the mediator. That means the frontend is not optional decoration: the Service, Guard, ErrorHandler and HttpInterceptor pieces are described as part of the architecture, and the documented run steps install the frontend before starting the backend. A team that wants a backend-only API will be deleting parts of the template rather than using it as shipped.

The README's layer descriptions are also prose, not enforcement. Nothing in the repository describes an architecture test, an analyzer rule or a build check that fails when a Domain type references Database. The boundaries depend on review. The README states the rule; it does not state a mechanism that catches a violation.

## Compared with a mediator library plus your own layout

The obvious alternative is to take a mediator package and a CQRS sample and assemble the pipeline yourself. The difference is what you inherit. A mediator library gives you the dispatch mechanism and leaves the folder structure, the Result pattern, the validation placement and the repository shape to you. rafaelfgx/Architecture gives you the dispatch mechanism plus a fixed answer for all of those, including the rule that handlers hold flow but not business rules.

That trade is worth naming precisely. With a library you pay assembly time and get freedom; with this template you pay nothing to start and get the author's decisions, which you then either keep or dismantle. The README's benefit list, standardized and centralized flow for validation, log, security and return, is exactly the part you would otherwise write yourself. The cost is that the Domain rules about entities and value objects are not negotiable within the template's own logic: if your model needs mutable entities, this layout fights you.

## Licence and the cost of staying current

The repository ships a license.md file and the project is MIT licensed. MIT permits use, modification and redistribution with the copyright notice retained; it does not grant trademark rights, and it offers no warranty. This is a description of the licence text, not legal advice, and the terms that matter for your organisation should be read from license.md itself.

Upgrade cost follows from the absence of releases. The README pins nothing: it names .NET, ASP.NET Core, Entity Framework Core, C#, Angular and UIkit as technologies, and the repository description names .NET 10 and Angular 22, but there is no compatibility matrix and no migration note. When you take an update, you are reading the diff. The last push to the default branch was on 2026-08-18. Whether that cadence suits you depends on how much of the template you have rewritten; the more you have changed, the less a future commit is worth to you.

## Conclusion

Adopt it if you want a working .NET 10 and Angular 22 skeleton with a Mediator request flow and folder-by-feature layout already wired up, and you can live with the layers as written. Do not adopt it if you need a published package to depend on, a documented migration or rollback path, or a solution that runs without SQL Server. Before committing, verify the .NET SDK and Node versions your toolchain resolves against the repository, confirm the ports 8090 and 1433 are free, and replace the SigningKey and SA_PASSWORD values that docker-compose.yaml ships with.

## FAQ

### How do I install and run rafaelfgx/Architecture?

The README gives four routes. The Docker route runs docker compose up --detach --build --force-recreate --remove-orphans from the repository root, then opens http://localhost:8090. The other routes install frontend dependencies with npm run restore in source/Web/Frontend, then start the backend with dotnet run or by pressing F5 in Visual Studio or Visual Studio Code.

### What are the prerequisites for rafaelfgx/Architecture?

The README lists the .NET SDK, SQL Server, Node and the Angular CLI for the command-line path, and adds Visual Studio Code with the C# extension or Visual Studio for the IDE paths. The Docker path needs only Docker.

### What is the folder-by-feature structure in rafaelfgx/Architecture?

The README lists Folder-by-Feature Structure among the project's principles and describes segregation by feature instead of technical type as a benefit. The Application layer carries this out through Request, Request Validator, Response and Handler types grouped per feature.

### Is rafaelfgx/Architecture a NuGet package I can add to an existing project?

No. The README points to a separate repository, rafaelfgx/DotNetCore, and a NuGet profile for packages. The Architecture repository is the full solution, backend and Angular frontend together, so adopting it means starting from its layout.

## Sources

- [Issues](https://github.com/rafaelfgx/Architecture/issues)
- [License: MIT](https://github.com/rafaelfgx/Architecture/blob/main/LICENSE)
- [rafaelfgx/Architecture on GitHub](https://github.com/rafaelfgx/Architecture)
- [README](https://github.com/rafaelfgx/Architecture/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rafaelfgx-architecture