.NET Enterprise Architecture is easier to get right when a team starts from a written blueprint instead of improvised habits. The stack in 2026 is settled — .NET 10, EF Core 10, Blazor Server, MudBlazor, MediatR, and JWT — so the remaining decisions are structural. This article is a practical blueprint: six steps that turn a greenfield .NET 10 repository into a codebase that stays coherent at fifty thousand lines and beyond, plus a one-page checklist you can paste into your project README.
A .NET Enterprise Architecture Blueprint, Step by Step
The steps below are ordered by leverage. Each one is cheap to do on day one and expensive to retrofit later, so resist skipping ahead.
Step 1: Choose the Container Shape Early
Start with one project. A single .NET 10 web project keeps the build fast, the DI container single, and navigation trivial. Draw the boundaries with folders and namespaces: one module per business capability, and vertical slices inside each module. If a module later outgrows the monolith, the folders lift out cleanly — the architecture supports the future without paying for it today.
Step 2: Make Security a Structural Feature
Wire ASP.NET Core Identity with JWT on the first day, not the last. Identity manages users, roles, and passwords; JWT secures the REST API for external clients and integrations. Express permissions as policies — CanManageOrders, CanApproveLeave — and apply the same policy to Blazor Server components and API endpoints. When the policy is the unit of security, the UI and the API cannot drift apart, and a new endpoint is secure by default.
Step 3: Standardize the Vertical Slice Contract
Every feature in the codebase should follow the same shape: a command or query, a validator, a handler, and a DTO. The invariant-bearing entities live in a small domain area. An aggregate root is the classic example — it owns its invariants and its lifecycle, so nothing can leave the object in an invalid state:
public sealed class Order : AggregateRoot
{
private readonly List<OrderLine> _lines = [];
public Guid CustomerId { get; private set; }
public OrderStatus Status { get; private set; }
public IReadOnlyCollection<OrderLine> Lines => _lines;
private Order() { }
public static Order Create(Guid customerId, IReadOnlyList<OrderLine> lines)
{
if (lines.Count == 0)
throw new DomainException("An order needs at least one line.");
var order = new Order
{
CustomerId = customerId,
Status = OrderStatus.Draft
};
order._lines.AddRange(lines);
order.RaiseDomainEvent(new OrderCreatedEvent(order.Id));
return order;
}
}The private constructor prevents bypassing the factory, the RaiseDomainEvent call lets other modules react without coupling, and EF Core maps the aggregate through its public surface. When every feature follows this contract, a new developer can read any slice and already know where everything lives.
Step 4: Expose a REST API Beside the Blazor UI
Build the REST API in the same project, sharing the same handlers the Blazor Server screens call. The UI and the API become two thin entry points over one domain, which removes an entire category of duplicated logic. Document it with Swagger from the first commit so the contract is always current, and protect it with the same JWT policies from step two.
Step 5: Test the Boundaries, Not the Framework
Write tests that verify the things you will regret if they break: validators reject bad input, handlers enforce business rules, aggregates cannot reach invalid states, and modules never reach into each other's tables. A boundary test is a few lines that walk the assembly and fail if an Inventory handler references an Orders-owned entity type. Those few tests do more for maintainability than a thousand framework assertions.
Step 6: Deploy Like a Product, Not a Prototype
A single-project application publishes to one artifact, which makes deployment boring — and boring is the goal. Set up the pipeline on day one: build, run tests, publish, apply EF Core 10 migrations as a script, and deploy to a container. Add health checks and structured logging now, while the wiring is visible, rather than reverse-engineering them from an incident later.
The One-Page .NET Enterprise Architecture Checklist
Print this list, or paste it into your README, and work through it before a feature is merged:
- One project, module folders, vertical slices — no new class library without a written reason
- JWT with ASP.NET Core Identity, expressed as policies, enforced on UI and API alike
- Every feature ships a command or query, validator, handler, and DTO in one folder
- Aggregates own their invariants; handlers never leave an entity in a bad state
- Cross-module communication through domain events only
- REST API documented with Swagger and sharing the same handlers as the UI
- Boundary tests green in CI; migrations generated and reviewed like code
- Health checks, structured logging, and a one-command deployment
FAQ
Is this blueprint also valid for a team already on .NET 8? Yes. Everything here is version-agnostic in spirit; .NET 10 simply ships the pieces — EF Core 10, ASP.NET Core 10, and Blazor Server — with the least friction. Retargeting a .NET 8 app is mostly a target-framework change.
Do I really need a separate REST API if Blazor Server is the UI? Yes, for integrations. Customers, mobile apps, and external tools need a documented contract, and JWT makes that contract safe. The sharing of handlers keeps the cost of the API close to zero.
How many projects should a large enterprise system have? As few as the team can defend. Most products need one web project plus a test project. Additional class libraries are justified only when something genuinely needs to be reused or versioned independently.
Where can I see this blueprint implemented end to end? Every Indotalent product is a complete .NET 10 codebase that follows exactly these six steps — Blazor Server, vertical slices, JWT, REST API, and CI-ready configuration, as full source code for $21 each.
Key Takeaways
- One project with module folders beats five projects with vague boundaries
- JWT with Identity and policies makes security structural, not an afterthought
- A standardized slice contract makes every feature predictable and reviewable
- Aggregates own their invariants and raise domain events for cross-module reactions
- Shared handlers mean the REST API and the Blazor UI never drift
- Boundary tests and a boring deployment keep the blueprint alive in CI
- Indotalent products implement this full blueprint in complete .NET 10 source code — $21 each