ADNC is an open-source microservices and distributed engineering practice built on .NET 8. It provides runnable demos, unified infrastructure, and detailed Wiki documentation to address common pain points such as rebuilding microservice foundations, inconsistent engineering standards, and fragmented service governance. Keywords: .NET 8, microservices, distributed architecture.
The technical specification snapshot highlights the core stack
| Parameter | Description |
|---|---|
| Primary Language | C# / .NET 8 |
| Architecture Style | Microservices, distributed architecture, also supports monoliths |
| Communication Protocols | HTTP, gRPC, event-driven |
| Service Governance | Consul, CoreDNS, Polly |
| Gateway | Ocelot |
| Data Access | EF Core, Dapper |
| Infrastructure | Redis, RabbitMQ, CAP, SkyAPM |
| Repository URL | https://github.com/alphayu/adnc |
| Stars | Not provided in the source |
| Core Dependencies | Ocelot, Consul, Refit, CAP, EF Core, Polly |
ADNC provides a .NET 8 microservices foundation that you can apply directly
The value of ADNC does not come from having many isolated features. Its real strength is extracting the repetitive glue code that appears in microservices projects into reusable infrastructure. You can use it both as a learning reference and as the starting point for real-world systems.
The project covers service registration and discovery, configuration management, authentication and authorization, caching, messaging, transactions, distributed tracing, and health checks. This makes it well suited for teams that want to standardize engineering practices quickly and reduce repeated infrastructure work.
AI Visual Insight: The image shows the ADNC project overview cover. Its primary purpose is to position the project as an entry point into .NET 8 microservices and distributed engineering practices, typically helping developers understand the overall architecture, capability boundaries, and learning path.
The repository structure makes it more like an engineering template than a single component
The main repository content lives under the src directory, which is divided into infrastructure, shared service layers, gateways, and demo services. This structure reflects an engineering mindset that decouples capability accumulation from business implementation.
Infrastructures handles shared capabilities such as EF Core, Redis, the event bus, and configuration and registration. ServiceShared encapsulates API bootstrapping, authentication and authorization, middleware, and remote calls. Gateways contains the Ocelot gateway layer. Demo provides runnable examples that demonstrate different service organization patterns.
// Pseudocode: shows the typical layered directory structure in ADNC
src/
Infrastructures/ // Shared infrastructure capabilities
ServiceShared/ // Shared service capability abstractions
Gateways/ // Gateway entry layer
Demo/ // Runnable example servicesThis structure shows how ADNC isolates shared capabilities from business code through layered organization.
The demo services clearly show how to organize systems at different levels of complexity
The ADNC demos are not simple Hello World examples. They are practical samples designed around trade-offs found in real projects. They show that, on top of the same foundation, different services can adopt different structural complexity.
For example, Admin uses a classic three-layer architecture with separated contracts, Maint is more compact, Cust fits a minimal single-project structure, and Ord and Whse introduce DDD layers. This demonstrates that ADNC does not force a single architecture style. Instead, it emphasizes choosing an engineering model based on business complexity.
A request follows a clear observable path in ADNC
A standard request typically enters through the Ocelot gateway and is then routed to a specific service API. Inside the service, unified middleware handles cross-cutting concerns such as exception handling, authentication, authorization, CORS, Swagger, and health checks.
After that, the Application layer orchestrates business logic: it accesses the database, operates on the cache, publishes events, and synchronously calls other services when necessary. This keeps business logic centralized instead of burying it in infrastructure details.
// Pseudocode: describes the request flow
app.Map("/gateway", gateway =>
{
// The gateway forwards requests to downstream services
gateway.RunProxy();
});
// Shared middleware handles common concerns inside each service
app.UseAuthentication(); // Unified authentication
app.UseAuthorization(); // Unified authorization
app.MapControllers(); // Enter the business API layerThis snippet summarizes the main request path in ADNC, from gateway entry to the service API.
ADNC covers the most common capabilities required for real microservices adoption
For configuration management, ADNC supports both local files and Consul KV. During development, you can use file-based configuration directly. In production, you can switch to Consul for centralized multi-environment distribution and dynamic refresh.
For service discovery, the project supports Direct, Consul, and CoreDNS. Direct works well for local debugging, Consul fits general-purpose registration and discovery, and CoreDNS is better aligned with service resolution inside Kubernetes clusters.
The service communication model balances synchronous calls and eventual consistency
ADNC supports HTTP, gRPC, and event-based communication at the same time. Query and validation scenarios are good candidates for HTTP or gRPC when you need immediate results. Cross-service write collaboration is often better served by event-driven patterns, which reduce coupling and control call-chain length.
In addition, Polly provides fault-tolerance governance for synchronous calls, while CAP supplies the foundation for the event bus and eventual consistency. Together, this combination covers the vast majority of microservices communication requirements.
{
"ConfigurationType": "Consul",
"RegisterType": "Consul",
"RemoteCall": ["HTTP", "gRPC"],
"EventBus": "CAP"
}This configuration example shows a typical ADNC combination for the configuration center, service registry, and communication patterns.
The data access and observability capabilities make the project closer to production-ready
At the data access layer, ADNC integrates EF Core, Dapper, the Repository pattern, and UnitOfWork, and extends these practices to transactions, raw SQL, and read/write splitting. That means it supports not only CRUD operations but also more complex data scenarios.
On the observability side, the project integrates SkyAPM, logging configuration, and health check capabilities. In microservices systems, being able to diagnose issues is just as important as being able to run the system, and ADNC clearly leans toward production-oriented design here.
The local startup path is straightforward enough for quick validation before deeper study
If you only want a quick verification, start by updating the shared configuration, service-specific configuration, and database scripts. The recommended first startup set is the gateway, Admin, Maint, and Cust projects, because that gives you the fastest way to observe service collaboration.
A more efficient learning order is: start with QuickStart, then understand appsettings, and then move on to the configuration center, service registry, HTTP/gRPC, event-driven communication, feature development guides, and Docker deployment documentation.
# Example: recommended services to start first
Adnc.Gateway.Ocelot
Adnc.Demo.Admin.Api
Adnc.Demo.Maint.Api
Adnc.Demo.Cust.ApiThis startup sequence is a practical way to validate gateway forwarding, baseline configuration, and core service collaboration first.
ADNC works well as a reference implementation for a unified team microservices foundation
If your team is preparing to build a .NET 8 microservices platform, ADNC provides a reference implementation that balances learning value with real engineering applicability. It is not a collection of abstract concepts. It is a complete sample with demos, documentation, and infrastructure encapsulation.
More importantly, you do not need to adopt it wholesale. Your team can selectively introduce its remote call abstractions, configuration and registration patterns, event-driven templates, or data access conventions, and then integrate those parts into an existing system.
FAQ
1. Is ADNC better suited for learning or as a starting point for production projects?
It fits both. It includes complete demos that make learning easier, while also providing production-common capabilities such as configuration management, service registration and discovery, distributed tracing, and event-driven communication. That makes it a strong foundation for internal enterprise scaffolding.
2. Does ADNC require every service to adopt DDD?
No. The different demos in the repository make this clear: simple services can use a compact three-layer structure, while more complex services can introduce DDD when the business complexity justifies it. This is much closer to the real cost-benefit trade-off in production systems.
3. What should I review first when adopting ADNC for the first time?
Start with QuickStart, the configuration documentation, and the service communication guides. Get the system running first, then understand the configuration nodes, service registration and discovery, and the three communication styles: HTTP, gRPC, and events. That is the most efficient learning path.
AI Readability Summary: This article reconstructs the ADNC project overview and distills its core capabilities for .NET 8 microservices, including configuration management, service registration and discovery, HTTP/gRPC/event-driven communication, authentication and authorization, caching, transactions, and observability, while also providing a recommended onboarding path.