ADNC is a .NET 8 modular monolith that keeps its service boundaries before its network boundaries

The first design principle is that distribution is a cost

ADNC describes itself as a pragmatic .NET 8 framework for modular business systems that can move from a modular monolith to distributed microservices. The word pragmatic does a lot of work in that sentence, and the section titled Why ADNC explains what it means.

The argument starts from a claim: distributed systems fail most often at the boundaries, and service ownership, data consistency, configuration drift and integration contracts are where the real complexity lives. From that, three pillars follow. Modular monolith first means designing strict boundaries from day one. Strategic evolution means extracting services only when scale justifies the complexity. Enterprise infrastructure means production-ready building blocks so teams work on business behaviour instead of plumbing.

Two of those pillars are negative statements, and they are worth repeating. The first asks you to stop the big ball of mud before it starts. The second says distributed systems are a cost, not a feature.

The first design principle restates that: service boundaries should be explicit before deployment boundaries become expensive. This is a position, not a neutral description, and if your organisation has already committed to microservices per bounded context from the start, this framework will feel like it is arguing with your architecture rather than supporting it.

The README spends a list on what ADNC is not

There is a section headed ADNC is not, and it is four bullets long. That is unusual in a project README and it is probably the most useful part of the document.

It is not a black-box platform that hides .NET application architecture. Whatever abstractions exist are meant to be visible, and a team should still understand how its ASP.NET Core application is put together.

It is not a code generator that produces architecture without intent. This rules out the scaffolding-and-forget category, where you run a tool and inherit a solution you did not design.

It is not a microservice-only template that forces every bounded context to be deployed independently from day one. That is the direct consequence of the modular-first position, and it means some of your services will stay in-process.

And it is not a benchmark claim. The wording here is that performance notes are scenario references, not guarantees. For a framework that bundles an API gateway, a database abstraction and an event bus, that disclaimer is the difference between an honest document and a marketing one.

The document also says the repository is both a framework and a working reference implementation, which is a good description of what you actually download.

Four layers, and the infrastructure packages are the reusable part

The architecture section splits the system into four parts, and the table is short enough to be worth reading twice.

The Gateway is an Ocelot-based API gateway handling routing, authentication integration, a Consul provider and resilience policies. Infrastructure is the set of reusable packages for Consul, Redis, repositories, the event bus, ID generation, helpers and core primitives. The Shared Service Layer holds common application, domain, repository, remote-call and web API building blocks. Demo Services are business services showing layered, compact and DDD-oriented structures.

The infrastructure packages live under `src/Infrastructures` with an `Adnc.Infra.*` namespace, and the naming is precise enough to be a map of the package set. `Adnc.Infra.Core` and `Adnc.Infra.Helper` hold primitives. `Adnc.Infra.Consul` covers service discovery and configuration. `Adnc.Infra.EventBus` is the event bus, and `Adnc.Infra.IdGenerater` does ID generation, misspelling and all.

Redis comes in two packages, `Adnc.Infra.Redis` and `Adnc.Infra.Redis.Caching`, which is the kind of split that tells you the caching decorator is separable from the connection handling.

The repository area is the largest. There is an abstraction in `Adnc.Infra.Repository`, then `Adnc.Infra.Repository.Dapper` for the hand-written SQL path, and four EF Core providers: `EfCore`, `EfCore.MySql`, `EfCore.SqlServer` and `EfCore.MongoDB`.

The README states these are published to NuGet as packages matching `adnc.infra`, which means you can take the persistence abstraction without the gateway and without the event bus.

It orchestrates the ecosystem instead of replacing it

One design principle states a preference for replaceable integrations over reinvention, and the list of what sits behind it is named: Consul, Cap, EF Core, Dapper, Redis and SkyAPM.

Cap is the event bus component, and it appears again in the feature list as CAP, described there as the event bus in a demo that also includes Gateway, Identity and SkyWalking for tracing. The stated approach is that ADNC orchestrates these behind consistent conventions rather than reinventing them.

That choice has a clear consequence for anyone evaluating this. The abstractions are thin by intent, so learning ADNC does not mean learning a proprietary messaging or caching model, it means learning a consistent way to configure Consul, Redis and Cap. That is a good deal for a team that already knows the .NET ecosystem and a bad one if you expected the framework to solve a problem those libraries do not.

The same principle appears in the responsibility table, where operational concerns are described as first-class citizens rather than afterthoughts: configuration, tracing, gateway routing and health checks are listed as core architectural requirements.

There is also a NuGet package list at the end of the infrastructure section, so the packages themselves rather than the repository are the adoption unit.

Three service shapes in one demo, on purpose

A detail that is easy to miss is that the demo domain does not use one project layout. The README says the framework demonstrates how different service shapes can coexist in the same system: classic layered services, compact single-project services, and DDD-style services with explicit domain layers.

The second design principle explains why. Different domains deserve different shapes, and a simple CRUD service should not be forced into the same complexity as a domain-heavy one. The goal is informed trade-offs across project styles.

This is a more interesting position than it first appears. Most templates show you one architecture and leave you to generalise it, and generalising a layered template into a DDD layout is a rewrite. Shipping all three shapes in a demo means the boundary between shared infrastructure and service-owned code is visible in each variant.

The repository layout supports the rest of the story: `src/` for code, `test/` for tests, `database/` for scripts, `deploy/` for Docker Compose infrastructure assets, and `docs/` for the documentation, which is described as available in English and Chinese. There is a `README_ZH.md` alongside the English one, so the Chinese documentation is the primary one and the English one accompanies it.

The site is hosted at aspdotnetcore.net and the CNAME file at the repository root is what maps the project name to that domain.

One release, a develop branch, and getting started is elsewhere

Two things about the project's state are worth knowing before you plan an evaluation.

The default branch is `develop`, not `main`. That is a normal choice for a framework with a maintainer handling releases, and it means the branch you see by default is the moving edge rather than a stable line.

Releases are thin. There is a single listed release, v1.0.2, published on 2026-04-26, and the last push was on 2026-04-29. So the code is being worked on, but there is not a history of tagged versions to consult for what changed when, and CHANGELOG-style release notes are not part of what this repository shows you.

Getting started is also not in the README you can read here. The table of contents links to a Getting Started anchor and a Documentation anchor, both of which point into the `docs/` directory, and that is where the setup steps live.

What the visible part does establish is where the packages come from, NuGet under the `adnc.infra` prefix, and that a Docker Compose infrastructure and database scripts exist so a working stack is reproducible rather than aspirational.

The licence is MIT.

Where ADNC is the wrong choice

Four cases.

If you need one library for one problem, this is the wrong size. The value here is a coherent set of infrastructure decisions across a whole system, and a project that needs event sourcing or a workflow engine should add that library instead.

If your team does not read Chinese, the friction is real. Documentation is bilingual with Chinese as the primary text, and code comments and commit messages in this ecosystem often follow it. You will be reading translated or second-language material for the parts that matter most.

If your architecture is already committed to independently deployed bounded contexts, the modular-first position works against you rather than for you, and you would end up fighting the framework's default of keeping things in-process.

There is a fourth risk that is not a mismatch but a maturity question. With one release and a default branch of `develop`, you are likely to be tracking moving code, and the framework touches your gateway, your persistence and your messaging in the same commit history. Read the `docs/` getting started material in full before you adopt it, and check which `Adnc.Infra.*` packages you actually reference, because each one drags a database, a cache or a service registry dependency into your build.

Editorial conclusion

Adopt ADNC if your team wants a modular monolith on .NET 8 with production infrastructure already wired, and you are willing to read Chinese-first documentation and adapt the demo domain rather than start from a blank solution. Skip it if you want a small library, a code generator, or a template that forces every context into its own deployable. Verify first which NuGet packages under the `adnc.infra` prefix you actually need, since the infrastructure layer is published piece by piece rather than as one dependency.

Frequently asked questions

Official sources

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