Clean Architecture Manga: a .NET 6 virtual wallet built around use cases
:cyclone: Clean Architecture with .NET6, C#10 and React+Redux. Use cases as central organizing structure, completely testable, decoupled from frameworks
At a glance
- What is it?
- Manga is a reference implementation of Clean Architecture in .NET 6 and C#, with a React+Redux client and a Docker Compose stack. It is a teaching codebase for structuring a modular application around use cases, not a wallet you would ship to customers.
- Who is it for?
- Adopt Manga if you are an engineer who learns architecture by reading and changing working code, and you want a .NET 6 sample where a use case, its presenter and its tests sit in one folder. Do not adopt it as the base of a real wallet or any service holding customer money: it is a sample, the README calls it one, and the release history stops at v1.0.0 in 2018.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 100 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Manga solves, and who it is written for
Most architecture samples show you a diagram and a folder tree. Manga shows you a running system. It is a virtual wallet: a customer registers an account, then manages the balance with Deposit, Withdraw and Transfer operations. Those three operations are the use cases, and the repository treats them as the central organizing structure rather than as services hanging off a controller.
The README states the intent plainly: a sample implementation of Clean Architecture principles with .NET Core, with use cases decoupled from frameworks and technology details, built from small components developed and tested in isolation. The audience is engineers who already write .NET code and want to see how the dependency rule survives contact with Entity Framework Core, an identity server, a web API and a single-page application.
It is not a starter kit for a product. There is no published package, no NuGet template, and the README frames the project as a place to learn from the community and submit pull requests. Treat it as a well-organized reading exercise with a working demo attached.
Use cases at the center, frameworks at the edge
The organizing idea is that a use case is a folder. Register, Get Customer Details, Deposit, Withdraw and Transfer each own their input, their output port, their interactor and their presenter. The wiki documents this directly: the Flow of Control page walks through the Register flow and the Get Customer Details flow, and the Design Patterns page names Controller, ViewModel and Presenter as the pieces around a use case.
The wiki also maps the code onto three named styles at once: Hexagonal (ports and adapters, with a left side for driving adapters and a right side for driven ones), Onion, and Clean Architecture. That is more than branding. It tells you where a new dependency is allowed to point. The Accounts API is the left-side adapter that turns HTTP into a use case call. Entity Framework Core and SQL Server sit on the right side behind an output port.
The trade-off is visible in the folder count. A single operation like Withdraw needs an interactor, a request model, a response model, a presenter and a controller endpoint before it does anything. For a wallet with three operations that is a reasonable price. For a CRUD screen it is not, and the repository does not pretend otherwise.
Running the Manga wallet with Docker Compose
The README gives two setup scripts, one per platform, both run from the .docker directory. On macOS or Linux you run the shell script; on Windows you run the PowerShell one. The scripts bring up the whole solution, not just the API.
cd .docker && ./setup.shAfter that, docker ps should show the stack running. Everything is published through NGINX on port 8081, and the README lists the routes: the wallet SPA, the accounts API under /accounts-api, the identity server under /identity-server, and SQL Server. The SQL Server connection string in the README uses the sa user and a Database named Accounts.
https://wallet.local:8081
https://wallet.local:8081/accounts-api
https://wallet.local:8081/identity-serverBrowse to the wallet URL and click Log In. The README warns that the certificate is self-signed and links to instructions for trusting it locally, so expect a browser warning on first load. This is the point where a reader can exercise Register, Deposit, Withdraw and Transfer against a real database instead of reading about them.
Three framework branches, one of them current
The README states that the project supports .NET 6 on the main branch, .NET 5 on the dotnet5.0 branch, and .NET Core 3.1 on the dotnet3.1 branch. The description on the repository names .NET 6, C# 10 and React+Redux. If you are evaluating the code against a modern target, main is the branch to read; the other two are historical.
This matters more than a version number usually does. Clean Architecture samples age in a specific way: the domain and use case layers survive framework churn almost untouched, while the composition root, the dependency injection wiring and the Entity Framework Core mappings are the parts that break. Manga's value is concentrated in the layers that age slowly, which is the argument for reading it even now.
The release list tells a different story from the branch list. The newest tagged release is v1.0.0 from 2018-04-23, described as a Clean Architecture solution with DDD, use cases and presenters. Everything since then has landed on branches without a tag. If you need a pinned version to diff against, you do not have one.
Where Manga is the wrong tool
The README's own framing is the first limitation: this is a sample. A sample optimizes for readability of the architecture, so it carries a full identity server, an NGINX reverse proxy and a SQL Server container to demonstrate a wallet with three operations. That is a lot of moving parts for a local demo, and the setup scripts assume Docker is available and that you can trust a self-signed certificate.
There is no documented production deployment path. The README does not describe how to run this outside the Compose stack, how to configure secrets other than the sa password shown in the connection string, or how to migrate the database for a real environment. Anyone who lifts the Accounts API out of the repository inherits that gap.
The codebase is also opinionated in a way that will fight some teams. If your team's convention is thin controllers calling application services, the presenter indirection here will read as ceremony. And if your domain is mostly data entry, the use case per folder layout costs more than it returns. Manga is a good answer to "how do I keep business rules out of my framework" and a poor answer to "how do I ship a CRUD admin panel this month."
How it differs from other Clean Architecture samples
The most common comparison point is Ardalis's Clean Architecture template, which is a dotnet new template: you install it, scaffold a solution, and start from generated code with its own opinions about validation, specifications and API endpoints. Manga is the opposite shape. It is a finished application you read and modify, and the README points you at the wiki for the flow of control rather than at a scaffolding command.
That difference decides which one you want. A template gives you a starting point and a maintenance relationship with whoever publishes it. A sample gives you a worked example with no upgrade path. Manga's wiki pages on Architecture Styles and Design Patterns are the real deliverable; the wallet is the vehicle for them. If you want to understand why a Presenter sits between an interactor and a controller, Manga shows the wiring. If you want a project skeleton with a CLI, this is not it.
A second difference is the front end. Manga ships a React+Redux client in the wallet-spa directory alongside the .NET services, so the sample covers the full path from a browser action to a use case and back. Most .NET architecture samples stop at the API boundary.
Licence, maintenance and upgrade cost
The repository is licensed under Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices and state changes in modified files. It is not legal advice, and if you plan to redistribute a derivative you should read the LICENSE file in the repository root rather than a summary.
The last push to the repository was on 2026-06-22, so the main branch is not abandoned, but the tagged releases end in 2018. Practically, that means your upgrade path is the branch history, not a version number. If you fork it, pin the commit you forked and expect to rebase manually rather than pull a release.
Upgrade cost concentrates in the infrastructure layer. Moving from the dotnet5.0 or dotnet3.1 branch to main is a framework migration of the API, the identity server and the Entity Framework Core setup, and the README offers no migration guide. The domain and use case layers are the part you can carry forward with the least rewriting, which is arguably the point the sample is making.
Editorial conclusion
Adopt Manga if you are an engineer who learns architecture by reading and changing working code, and you want a .NET 6 sample where a use case, its presenter and its tests sit in one folder. Do not adopt it as the base of a real wallet or any service holding customer money: it is a sample, the README calls it one, and the release history stops at v1.0.0 in 2018. Before you copy anything, open the Accounts API project and the .docker setup scripts, confirm which of the three supported branches matches your target framework, and check that the Docker Compose stack still builds on your machine. The repository's last push was on 2026-06-22, so the code is alive, but the tagged releases are not where the recent work is.
Frequently asked questions
Are DDD and Clean Architecture the same thing?
No. Manga is described as a Clean Architecture solution with DDD, use cases and presenters, so the repository treats them as separate concerns that are combined in one sample. DDD shapes the domain model and its language; Clean Architecture shapes where dependencies are allowed to point.
What are the drawbacks of clean architecture?
In Manga the cost is visible in the folder count: one operation such as Withdraw involves an interactor, a request model, a response model, a presenter and a controller endpoint. For a small CRUD feature that indirection buys little, which is why the repository is a wallet with three operations rather than a general-purpose admin app.
Is MVC a clean architecture?
Manga does not equate the two. It uses a Controller and a ViewModel as design patterns on the left side of the architecture, with a Presenter between the use case and the output, so the controller is an adapter rather than the organizing structure of the application.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/ivanpaulovich-clean-architecture-manga)