DEV Community: ismail Cagdas

Angular + ASP.NET Core: Enterprise Project Getting Started Guide

ismail Cagdas — Thu, 02 Apr 2026 10:29:43 +0000

If you are building an enterprise web application in 2026, the combination of Angular and ASP.NET Core is one of the strongest choices you can make. Angular gives you TypeScript safety, a powerful component architecture, and a mature ecosystem. ASP.NET Core gives you a high-performance, cross-platform backend with first-class dependency injection and a rich middleware pipeline.

In this post, we will walk through three different ways to start an Angular + ASP.NET Core project — from a fully manual setup to a one-click enterprise starter. By the end, you will have a clear understanding of which approach fits your project best.

Prerequisites
Approach 1 — Manual Setup
- Step 1: Create the Angular App
- Step 2: Create the ASP.NET Core Web API
- Step 3: Configure CORS
- Step 4: Set Up the Angular Proxy
- Step 5: Make the First API Call
Approach 2 — Visual Studio Template
Approach 3 — ASP.NET Zero
Comparison
Common Issues and Solutions
Next Steps

Prerequisites

Before we start, make sure you have the following tools installed:

Node.js 24.x or later — download here
Angular CLI 21.x — install with npm install -g @angular/cli
.NET 10 SDK — download here
Visual Studio 2026 (Latest stable version) or VS Code with the C# Dev Kit extension
A terminal you are comfortable with (PowerShell, bash, or the VS Code integrated terminal)

You can verify your setup by running:

node --version    # v24.x (use latest stable)
ng version        # Angular CLI 21.x
dotnet --version  # 10.x

Approach 1 — Manual Setup

This approach gives you full control over every detail. It is the best choice if you want to understand how the pieces fit together or if you have specific architectural requirements.

Step 1: Create the Angular App

Open a terminal and run:

ng new MyApp.Client --style=scss --routing=true --ssr=false
cd MyApp.Client
ng serve

Navigate to http://localhost:4200 — you should see the default Angular welcome page.

Step 2: Create the ASP.NET Core Web API

Open a new terminal in the parent directory and create the API project:

dotnet new webapi -n MyApp.Api --use-controllers
cd MyApp.Api

Let's add a simple endpoint to test the connection. Open Controllers/WeatherForecastController.cs — the template already includes a GET /WeatherForecast endpoint that returns random forecast data. We will use this for our first integration test.

Run the API:

dotnet run

The API will start on a port shown in the terminal output (e.g. http://localhost:5266). You can verify it by navigating to http://localhost:{port}/WeatherForecast in your browser. Take note of this port — you will need it for the proxy configuration in Step 4.

Step 3: Configure CORS

By default, your Angular app on localhost:4200 cannot call the API on localhost:5001 because of the browser's same-origin policy. We need to enable CORS on the API side.

Open Program.cs and add the following:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddOpenApi();

// Add CORS policy
builder.Services.AddCors(options =>
{
    options.AddPolicy("Angular", policy =>
    {
        policy.WithOrigins("http://localhost:4200")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();

// Use the CORS policy
app.UseCors("Angular");

app.UseAuthorization();
app.MapControllers();
app.Run();

Note: This CORS configuration is for development only. In production, you should restrict the allowed origins to your actual domain.

Step 4: Set Up the Angular Proxy

While CORS works, a cleaner approach during development is to use Angular's built-in proxy. This way, the Angular dev server forwards API requests to the backend, and you avoid CORS entirely.

Create a file called proxy.conf.json in the root of your Angular project:

{
  "/WeatherForecast": {
    "target": "http://localhost:5266",
    "secure": false,
    "changeOrigin": true
  }
}

Note: Replace 5266 with the actual port your API is running on. You can find it in the terminal output when you run dotnet run — look for the line that says Now listening on: http://localhost:XXXX. Also, we are proxying the /WeatherForecast path directly because the default .NET template does not use an /api prefix. In a real project, you would typically add a common prefix like /api to all your controllers (using [Route("api/[controller]")]) and proxy that single prefix instead.

Update angular.json to use the proxy. Find the serve section and add the proxyConfig option:

"serve": {
  "options": {
    "proxyConfig": "proxy.conf.json"
  }
}

Now restart the Angular dev server with ng serve. Any request to /WeatherForecast from your Angular app will be forwarded to the .NET backend.

Step 5: Make the First API Call

Let's update the root component to fetch weather data from the API. First, we need to configure HttpClient. Open src/app/app.config.ts and add provideHttpClient():

import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideHttpClient } from '@angular/common/http';

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient()
  ]
};

Now open src/app/app.ts and update it:

import { Component, inject, OnInit, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';

interface WeatherForecast {
  date: string;
  temperatureC: number;
  temperatureF: number;
  summary: string;
}

@Component({
  selector: 'app-root',
  templateUrl: './app.html',
  styleUrl: './app.scss'
})
export class App implements OnInit {
  private http = inject(HttpClient);
  forecasts = signal<WeatherForecast[]>([]);

  ngOnInit() {
    this.http.get<WeatherForecast[]>('/WeatherForecast')
      .subscribe(data => this.forecasts.set(data));
  }
}

Then update src/app/app.html with the template:

<h1>Weather Forecast</h1>
@if (forecasts().length > 0) {
  <table>
    <thead>
      <tr>
        <th>Date</th>
        <th>Temp (C)</th>
        <th>Temp (F)</th>
        <th>Summary</th>
      </tr>
    </thead>
    <tbody>
      @for (f of forecasts(); track f.date) {
        <tr>
          <td>{{ f.date }}</td>
          <td>{{ f.temperatureC }}</td>
          <td>{{ f.temperatureF }}</td>
          <td>{{ f.summary }}</td>
        </tr>
      }
    </tbody>
  </table>
}

Save the file and check your browser. You should see the weather data rendered in a table. Your Angular frontend is now talking to your ASP.NET Core backend.

Approach 2 — Visual Studio Template

If you prefer a faster start with less manual configuration, Visual Studio 2022 ships with a built-in Angular + ASP.NET Core project template.

Open Visual Studio 2026 and select Create a new project.
Search for "ASP.NET Core with Angular" and select the template.
Configure the project name, location, and solution name.
On the next screen, select .NET 10 as the target framework.
Click Create.

Visual Studio generates a solution with two projects:

An ASP.NET Core backend with a sample WeatherForecast API.
An Angular frontend with proxy configuration already wired up.

Press F5 to run the project. Both the backend and the frontend will start together, and you will see a working Angular app fetching data from the API.

What you get out of the box:

Pre-configured proxy (proxy.conf.js)
HTTPS development certificate setup
Integrated launch profiles for debugging both projects simultaneously

What you don't get:

Authentication / authorization
Multi-tenancy
Role management
A production-ready UI framework

This template is a great starting point for prototypes or simple applications. For enterprise projects, you will need to add these features yourself — or use a framework that includes them. But, be aware that this option may have problems time to time because some pf the NPM packages intorduce breaking changes and it takes time for maintainer team to release a working version.

Approach 3 — ASP.NET Zero

ASP.NET Zero is a production-ready starter kit built on ASP.NET Core that supports Angular, React, and MVC (Razor) as frontend options. It is designed specifically for enterprise applications and includes dozens of features out of the box.

Here is how to get started:

Go to aspnetzero.com and sign up for a license.
Navigate to the Download page, select Angular as your frontend, and download the project.
Open the solution in Visual Studio or VS Code.
Update the database connection string in appsettings.json.
Run the migrator project to create and seed the database:

cd src/MyProject.Migrator
dotnet run

Start the backend:

cd src/MyProject.Web.Host
dotnet run

Start the Angular frontend:

cd angular
yarn 
yarn create-dynamic-bundles
yarn start

Navigate to http://localhost:4200 and log in with the default admin credentials. You will see a fully working enterprise application.

To run the project propertly, you can follow Angular Getting Started Document.

What you get out of the box:

Authentication & Authorization: Login, registration, two-factor authentication, social logins, LDAP/Active Directory integration — all pre-built and configurable.
Multi-Tenancy: Host/tenant architecture with separate databases or shared database options. Tenant registration, subscription management, and edition management are built in.
Role & Permission Management: A granular permission system with role-based and user-based authorization.
Organization Units: Hierarchical organizational structure with the ability to assign users and roles per unit.
Audit Logging: Every action is logged with user, timestamp, and change details.
Real-Time Notifications: Built-in notification system with SignalR integration.
UI Theme: A polished admin theme based on Metronic with responsive design, dark mode, and multiple layout options.
Power Tools: A Visual Studio extension and a CLI tool that generates entities, DTOs, application services, API controllers, Angular components, and unit tests from a simple entity definition. Instead of writing CRUD code manually, you describe your entity and Power Tools generates everything.

Let's see Power Tools in action. Say you want to add a Product entity to your application. You define the entity fields (Name, Price, Category, etc.) in Power Tools, click Generate, and it creates:

The Product entity and database migration
ProductAppService with full CRUD operations
ProductDto and CreateProductDto classes
Angular components for listing, creating, and editing products
Unit tests for the app service
UI tests for your Angular pages

What would take hours of boilerplate coding is done in under a minute.

Comparison

Here is how the three approaches compare:

Feature	Manual Setup	VS Template	ASP.NET Zero
Setup time	30-60 min	5 min	10 min
Authentication	You build it	You build it	Built-in
Authorization / Roles	You build it	You build it	Built-in
Multi-tenancy	You build it	You build it	Built-in
Organization units	You build it	You build it	Built-in
Audit logging	You build it	You build it	Built-in
UI theme	None	Basic	Metronic (production-ready)
Code generation tools	None	None	Power Tools
Real-time notifications	You build it	You build it	Built-in
Learning value	High	Medium	High
Flexibility	Full	Full	Full (source code included)
Cost	Free	Free	Licensed

Bottom line: If you are learning or building a simple prototype, the manual setup or VS template is perfect. If you are building an enterprise application and want to skip months of infrastructure work, ASP.NET Zero gives you a massive head start.

Common Issues and Solutions

CORS Errors

Symptom: The browser console shows Access to XMLHttpRequest has been blocked by CORS policy.

Solution: Make sure your Program.cs includes the CORS middleware and that app.UseCors() is called before app.UseAuthorization(). Also verify that the origin URL matches exactly (including the port number and protocol).

// Correct order
app.UseCors("Angular");
app.UseAuthorization();

Proxy Not Working

Symptom: API calls return 404 or the Angular app tries to serve the request itself.

Solution: Double-check the proxy.conf.json path in angular.json. Make sure the target URL matches the port your API is running on. Restart ng serve after any proxy configuration change — the proxy config is only read at startup.

SSL Certificate Errors

Symptom: ERR_CERT_AUTHORITY_INVALID or proxy shows UNABLE_TO_VERIFY_LEAF_SIGNATURE.

Solution: For development, set "secure": false in your proxy.conf.json. This tells the Angular dev server to accept self-signed certificates. Alternatively, trust the .NET development certificate:

dotnet dev-certs https --trust

Angular CLI Version Mismatch

Symptom: Build errors or unexpected behavior after creating the project.

Solution: Make sure your global Angular CLI version matches the version in the project's package.json. You can check with ng version and update with:

npm install -g @angular/cli@19

Next Steps

Now that your Angular + ASP.NET Core project is up and running, here are some next steps depending on which approach you chose:

Add authentication: If you went with the manual setup or VS template, check out the ASP.NET Core Identity documentation to add login and registration.
Explore ASP.NET Zero: If you are interested in the enterprise approach, contact ASP.NET Zero Team and explore the documentation. The Angular getting started guide will have you running in under 10 minutes.
Try Power Tools: If you are already using ASP.NET Zero, generate your first entity with Power Tools and see how much time it saves.

Building enterprise applications is hard. Choosing the right foundation makes it significantly easier. Whether you start from scratch or stand on the shoulders of a mature framework, Angular and ASP.NET Core together give you a rock-solid stack for 2026 and beyond.

What .NET 10 LTS Means for Enterprise Applications

ismail Cagdas — Wed, 21 Jan 2026 05:45:09 +0000

If you are running enterprise applications on .NET 8 or .NET 9, there is an important date you need to mark on your calendar: November 10, 2026.

On that day, both .NET 8 and .NET 9 will reach end of support—simultaneously. This is not a typo. Due to Microsoft's decision to extend Standard Term Support (STS) from 18 to 24 months, both versions now share the same end-of-life date.

This creates a unique situation for enterprise teams: whether you played it safe with .NET 8 LTS or chased the latest features with .NET 9, you now face the same migration deadline.

The target? .NET 10 LTS, released in November 2025 and supported until November 2028.

The Support Timeline You Need to Understand

Microsoft follows a predictable release cadence: even-numbered releases are Long Term Support (LTS) with three years of support, while odd-numbered releases are Standard Term Support (STS) with 18-24 months.

Here is the current state of .NET support:

Version	Release Type	End of Support
.NET 6	LTS	November 12, 2024 (Already EOL)
.NET 7	STS	May 14, 2024 (Already EOL)
.NET 8	LTS	November 10, 2026
.NET 9	STS	November 10, 2026
.NET 10	LTS	November 10, 2028

If you are still running .NET 6 or .NET 7, you are already operating on unsupported frameworks. No security patches. No bug fixes. This is a compliance risk that needs immediate attention.

Why .NET 10 LTS Matters for Enterprise

Every two years, Microsoft releases an LTS version. Usually, it is the "safe" choice—the boring, stable option that enterprises pick while developers chase newer features. This time is different.

.NET 10 LTS is not just a stability release. It is a significant leap forward in performance, security, and AI readiness.

1. Performance That Impacts Your Bottom Line

The performance improvements in .NET 10 are not incremental. Real-world benchmarks show:

30-50% performance improvements from JIT inlining, method devirtualization, and stack allocation optimizations
40-60% reduction in memory usage through array interface de-virtualization
60-80% improvements in specific high-throughput scenarios

For enterprise applications, this translates directly to infrastructure savings. If your cloud bill is tied to CPU and memory consumption, .NET 10 can meaningfully reduce your costs without changing a single line of business logic.

2. Security and Compliance Acceleration

Enterprise applications live and die by compliance requirements. .NET 10 strengthens your security posture through:

Updated cipher suites with modern cryptographic standards
Improved request validation and hardened default configurations
Enhanced vulnerability patching workflows
Post-quantum cryptography support via Windows CNG

That last point deserves attention. Financial services, government contractors, and healthcare organizations are already being asked about quantum-resistant encryption strategies. .NET 10's built-in post-quantum cryptography support checks that compliance box automatically.

3. AI-Ready Infrastructure

.NET 10 arrives with built-in AI integration through the new Microsoft Agent Framework. Combined with expanded ML.NET capabilities and new tensor APIs, your applications are positioned to integrate AI features without bolting on external dependencies.

This is not about hype. It is about having the foundation in place when your business stakeholders inevitably ask for AI-powered features.

4. Entity Framework Core 10: Enterprise Data Features

For data-driven enterprise applications, EF Core 10 brings two significant additions:

Vector search support for SQL Server 2025 and Azure SQL Database—enabling embeddings and similarity search directly in your ORM
Native JSON type support for the new SQL Server JSON data type

If your roadmap includes semantic search, recommendation engines, or any AI/ML features that rely on vector embeddings, EF Core 10 eliminates the need for specialized vector databases in many scenarios.

The Migration Decision Matrix

Not every organization has the same constraints. Here is how to think about your migration strategy:

If You Are on .NET 9

This is the easiest path. You are moving from a 2-year STS window to a 3-year LTS window. Most projects can complete this migration in 2-5 days. The breaking changes are minimal, and you gain 2.5 additional years of support.

Recommendation: Migrate immediately. There is no reason to wait.

If You Are on .NET 8 LTS

You have until November 2026, but do not let that create complacency. The performance improvements alone justify an earlier migration. Plan your upgrade cycle for Q2 2026 at the latest to allow buffer for testing.

Recommendation: Start planning now. Execute migration by mid-2026.

If You Are on .NET 6 or .NET 7

You are running unsupported frameworks. Every day without patches is a day of accumulated security risk. This is not a feature migration—it is a critical security remediation.

Recommendation: Treat this as a P1 priority. Migrate immediately.

If You Are on .NET Framework 4.8

The jump to .NET 10 is significant but achievable. Modern tooling, including AI-assisted migration with GitHub Copilot, makes this transformation practical. The benefits—cross-platform support, containerization, modern performance—justify the investment.

Recommendation: Begin assessment now. Plan a phased migration over the next 12-18 months.

Tooling Requirements: The Visual Studio Question

There is one critical constraint: .NET 10 requires Visual Studio 2026. Visual Studio 2022 cannot target .NET 10 or use C# 14 features.

For enterprises with standardized development environments, this means:

VS Code + C# Dev Kit is a fully supported alternative available today
Visual Studio 2026 GA is expected in early 2026
Most enterprises should wait for VS 2026 GA before full rollout, but developers can start with VS Code immediately

This is not a blocker, but it does need to factor into your planning.

Breaking Changes to Prepare For

Every major release brings breaking changes. Here are the ones that will impact most enterprise applications:

WebHostBuilder and IWebHost Are Obsolete

The legacy hosting model is deprecated. If your applications still use WebHostBuilder, you need to migrate to WebApplicationBuilder. This is the direction Microsoft has been pushing since .NET 6, and .NET 10 makes it explicit.

Before:

var host = new WebHostBuilder()
    .UseKestrel()
    .UseStartup<Startup>()
    .Build();

After:

var builder = WebApplication.CreateBuilder(args);
// Configure services
var app = builder.Build();
// Configure middleware
app.Run();

WithOpenApi Extension Method Removed

If you are using the WithOpenApi() extension method for minimal APIs, it has been removed. Use the updated OpenAPI generator features instead.

Default Images Now Use Ubuntu

.NET container images now default to Ubuntu instead of Debian. If your deployment pipelines or Dockerfiles assume Debian-specific packages, you will need to update them.

The Three-Year Runway

.NET 10 LTS support extends until November 2028. This gives your organization three full years to:

Stabilize on a modern, performant runtime
Adopt AI and ML features at your own pace
Plan the next major upgrade cycle without pressure

Compare this to the version hopscotch of STS releases. For enterprise applications that value stability and predictability, .NET 10 LTS is the clear choice.

Conclusion: The Time to Act Is Now

The convergence of .NET 8 and .NET 9 end-of-support dates creates a forcing function. Every .NET application in your portfolio needs to be on .NET 10 by November 2026.

But this is not just about avoiding end-of-life. .NET 10 delivers genuine improvements:

Performance gains that reduce infrastructure costs
Security features that accelerate compliance
AI integration that positions you for the future
Three years of LTS support that provides stability

Start your assessment now. Identify your applications, understand your dependencies, and plan your migration timeline. The runway to November 2026 is shorter than it appears.

A Review of AI-Assisted Development Tools and My Workflow

ismail Cagdas — Thu, 15 Jan 2026 11:28:22 +0000

The world of software development is buzzing with the promise of Artificial Intelligence, and like many of you, I've been exploring the growing landscape of AI-assisted development tools. As a .NET/ASP.NET Core developer and open-source contributor, I've been piecing together a workflow that helps me leverage these powerful assistants. It's been a journey of discovery, full of pleasant surprises and a few hurdles.

Here's a look at the tools in my current rotation and the workflow I've settled on for now.

My AI Toolkit: A Review of Development Assistants

Vibe Kanban: The Mission Control

I start most of my tasks in Vibe Kanban. Its strength lies in its flexibility. I can connect it to multiple repositories and, more importantly, assign different AI models to different tasks. I have access to GitHub Copilot, Gemini, and Claude, and Vibe Kanban lets me switch between them seamlessly. This is perfect for running multiple tasks in parallel, though I've found that reviewing the generated output is still a time-consuming but necessary step.

Claude: The Master Planner

Claude is my go-to for planning. I find it's excellent at understanding programming concepts and laying out a structured plan. The main drawback is the token expiration, which can sometimes be a bit of a nuisance. If I have enouhg limit, mostly I ask Claude to implement Phase 1 of the plan it created.

Cursor: The Coder

When it's time to write code, I turn to Cursor. Its "auto mode" is a standout feature, as it's incredibly efficient with token usage, which is a major concern in AI-assisted development. However, as a .NET developer, I sometimes find it challenging to work on my projects within Cursor and occasionally have to switch back to Rider or Visual Studio for certain tasks.

Gemini: The Technical Writer

Interestingly, I don't use Gemini much for coding. Instead, it has become my trusted partner for writing technical articles and documentation. In this area, it truly excels.

GitHub Copilot: The Dependable Backup

I use GitHub Copilot less frequently than the others, but it's a reliable tool for smaller tasks, especially when I've run out of tokens on other platforms.

My AI-Powered Development Workflow

My process has evolved into a multi-stage workflow that leverages the strengths of different AI tools:

Plan with Claude: I start by asking Claude to create a detailed plan in a markdown format using Vibe Kanban.
Review and Refine: I thoroughly review the plan. If any adjustments are needed, I'll work with Claude to refine it.
Branch and Commit: Once the plan is solid, I create a new branch and commit the plan file. This provides clear context for the work that follows.
Code with Cursor: With the plan in hand, I open Cursor and begin the development work, following the roadmap laid out by Claude.
AI-Assisted Review: After the initial coding is done, I use another AI to review the changes and suggest improvements.
Manual Verification: The final step is always a manual review and testing of the functionality to ensure everything works as expected.

What's Next?

My next goal is to automate the testing phase. I plan to create a process that runs automated tests before I begin my manual review, which should help streamline the final verification step.

What's Your Workflow?

This is just a snapshot of my current process, and I'm sure it will continue to evolve. I'm curious to hear about your experiences. What tools are you using for AI-assisted development, and what does your workflow look like? Feel free to share your thoughts and recommendations!

An Opinionated Solution Structure for ASP.NET Core Projects

ismail Cagdas — Mon, 12 Jan 2026 12:23:07 +0000

As software projects grow, maintaining a clean and organized codebase becomes increasingly challenging. A well-thought-out solution structure can make the difference between a maintainable application and a tangled mess of dependencies. In this article, I'll walk you through the opinionated solution structure we use in ABP Framework — a structure that has proven itself in thousands of production applications.

Why Solution Structure Matters

Before diving into the details, let's understand why investing time in your solution structure pays off:

Maintainability: Clear boundaries make code easier to understand and modify
Testability: Well-separated layers are easier to test in isolation
Team Collaboration: Developers can work on different layers without conflicts
Scalability: A good structure grows with your application

The Root Level

We have a sample project named Acme.BookStore. I will try to explain the solution structure using this sample ASP.NET Core application.
Let's start with what you'll find at the root of the solution:

Acme.BookStore/
├── src/                    # Source projects
├── test/                   # Test projects
├── Acme.BookStore.sln      # Solution file
├── common.props            # Shared MSBuild properties
├── global.json             # SDK version pinning
└── NuGet.Config            # Package source configuration

The separation of src/ and test/ folders provides immediate clarity. The common.props file centralizes build configurations, ensuring consistency across all projects.

Source Projects: A Layered Architecture

The src/ folder contains the heart of your application, organized into distinct layers:

Domain Shared (`Acme.BookStore.Domain.Shared`)

This is the foundation layer with zero dependencies on other project layers. It contains:

Constants and enums
Shared value objects
Localization resources
Exception codes

// Example: BookType enum that can be shared across all layers
public enum BookType
{
    Adventure,
    Biography,
    Fiction,
    Science
}

Why separate this? These elements are often needed by multiple layers and even external clients. Keeping them in a dedicated project prevents circular dependencies.

Domain (`Acme.BookStore.Domain`)

The core business logic lives here:

Entities and aggregate roots
Repository interfaces (not implementations!)
Domain services
Domain events

public class Book : AggregateRoot<Guid>
{
    public string Name { get; set; }
    public BookType Type { get; set; }
    public DateTime PublishDate { get; set; }
}

This layer is infrastructure-agnostic — it doesn't know about databases, APIs, or UI frameworks.

Application Contracts (`Acme.BookStore.Application.Contracts`)

This project defines the application layer's public API:

Data Transfer Objects (DTOs)
Application service interfaces
Permission definitions

public interface IBookAppService : IApplicationService
{
    Task<BookDto> GetAsync(Guid id);
    Task<PagedResultDto<BookDto>> GetListAsync(GetBookListDto input);
    Task<BookDto> CreateAsync(CreateBookDto input);
}

Key benefit: This project can be shared with clients (like a Blazor WebAssembly app) without exposing implementation details.

Application (`Acme.BookStore.Application`)

Implementation of the application services:

Application service implementations
Object mapping configurations
Business workflow orchestration

public class BookAppService : ApplicationService, IBookAppService
{
    private readonly IRepository<Book, Guid> _bookRepository;

    public async Task<BookDto> GetAsync(Guid id)
    {
        var book = await _bookRepository.GetAsync(id);
        return ObjectMapper.Map<Book, BookDto>(book);
    }
}

Entity Framework Core (`Acme.BookStore.EntityFrameworkCore`)

Infrastructure layer for data access:

DbContext implementation
Repository implementations
Entity configurations
Database migrations

public class BookStoreDbContext : AbpDbContext<BookStoreDbContext>
{
    public DbSet<Book> Books { get; set; }

    protected override void OnModelCreating(ModelBuilder builder)
    {
        base.OnModelCreating(builder);
        builder.Entity<Book>(b =>
        {
            b.ToTable("Books");
            b.Property(x => x.Name).IsRequired().HasMaxLength(128);
        });
    }
}

HTTP API (`Acme.BookStore.HttpApi`)

API controllers that expose your application services:

[Route("api/books")]
public class BookController : AbpController
{
    private readonly IBookAppService _bookAppService;

    [HttpGet("{id}")]
    public Task<BookDto> GetAsync(Guid id)
    {
        return _bookAppService.GetAsync(id);
    }
}

HTTP API Client (`Acme.BookStore.HttpApi.Client`)

This is a powerful pattern — typed HTTP client proxies for consuming your API:

// Consumers can use IBookAppService directly
// The proxy handles HTTP calls transparently
var books = await _bookAppService.GetListAsync(new GetBookListDto());

This enables code sharing between server and client applications, reducing duplication and ensuring type safety.

Web (`Acme.BookStore.Web`)

The UI layer — whether Razor Pages, Blazor, or MVC:

Pages/Components
View models
Static assets
UI-specific configurations

Database Migrator (`Acme.BookStore.DbMigrator`)

A console application for:

Running database migrations
Seeding initial data
DevOps-friendly deployment scenarios (Like updating all tenant databases if you use database-per tenant approach)

Test Projects: Comprehensive Coverage

The test/ folder mirrors the source structure:

Project	Purpose
`TestBase`	Shared test infrastructure and utilities
`Domain.Tests`	Unit tests for domain logic
`Application.Tests`	Application service integration tests
`EntityFrameworkCore.Tests`	Repository and database tests
`HttpApi.Client.ConsoleTestApp`	End-to-end API testing
`Web.Tests`	UI layer tests

This structure makes it clear what you're testing and enables focused test runs during development.

Key Benefits of This Structure

1. Clear Separation of Concerns

Each project has a single, well-defined responsibility. Developers immediately know where to find and place code.

2. Dependency Inversion in Practice

The domain layer defines repository interfaces; the infrastructure layer implements them. Your business logic remains pure.

3. Shareable Contracts

The .Domain.Shared and .Application.Contracts projects can be packaged as NuGet packages and shared:

Across microservices
With client applications
With external integrators

4. Testability by Design

Each layer can be tested in isolation with appropriate mocking strategies.

5. Database Independence

Switching from SQL Server to PostgreSQL? Only the EntityFrameworkCore project needs changes.

6. Ready for Growth

This structure naturally evolves into modular monolith or microservices architectures.

Beyond Monolith: Modular and Microservice Architectures

While this article focuses on a single application structure, the same principles scale beautifully:

Modular Monolith

You can organize your solution into independent modules, each following this layered structure. Modules communicate through well-defined interfaces, giving you the benefits of microservices without the operational complexity.

Microservices

Each microservice can follow this exact structure, with the .Domain.Shared and .Application.Contracts projects published as NuGet packages for inter-service communication.

ABP Framework provides comprehensive templates and guidance for both architectures. Check out the ABP Framework GitHub repository for:

Modular application templates
Microservice solution templates
Real-world sample applications

Getting Started

If you'd like to try this structure yourself, ABP Framework provides CLI tools to generate solutions with this exact architecture:

dotnet tool install -g Volo.Abp.Studio.Cli
abp new Acme.BookStore -m none --theme leptonx-lite -csf --connection-string "Server=(LocalDb)\\MSSQLLocalDB;Database=BookStore;Trusted_Connection=True;TrustServerCertificate=true"

Or, you can go to https://abp.io/get-started page and select other options like PostgreSQL, MongoDB, Angular, Blazor etc...

Conclusion

A well-organized solution structure is an investment that pays dividends throughout your project's lifecycle. The layered architecture presented here — with its clear separation between domain, application, infrastructure, and presentation layers — provides a solid foundation for building maintainable, testable, and scalable ASP.NET Core applications.

I encourage you to explore the ABP Framework on GitHub to see this structure in action across numerous modules and sample applications. As one of the developers of ABP Framework, I've seen firsthand how this architecture helps teams build robust applications efficiently.

Whether you're building a simple CRUD application or an enterprise-grade distributed system, starting with a clean structure will serve you well. Happy coding!

Have questions or feedback? Feel free to open an issue on the ABP Framework GitHub repository or join our community discussions.

An Opinionated Solution Structure for ASP.NET Core Projects

Why Solution Structure Matters

Before diving into the details, let's understand why investing time in your solution structure pays off:

Maintainability: Clear boundaries make code easier to understand and modify
Testability: Well-separated layers are easier to test in isolation
Team Collaboration: Developers can work on different layers without conflicts
Scalability: A good structure grows with your application

The Root Level

We have a sample project named Acme.BookStore. I will try to explain the solution structure using this sample ASP.NET Core application.
Let's start with what you'll find at the root of the solution:

Acme.BookStore/
├── src/                    # Source projects
├── test/                   # Test projects
├── Acme.BookStore.sln      # Solution file
├── common.props            # Shared MSBuild properties
├── global.json             # SDK version pinning
└── NuGet.Config            # Package source configuration

The separation of src/ and test/ folders provides immediate clarity. The common.props file centralizes build configurations, ensuring consistency across all projects.

Source Projects: A Layered Architecture

The src/ folder contains the heart of your application, organized into distinct layers:

Domain Shared (`Acme.BookStore.Domain.Shared`)

This is the foundation layer with zero dependencies on other project layers. It contains:

Constants and enums
Shared value objects
Localization resources
Exception codes

// Example: BookType enum that can be shared across all layers
public enum BookType
{
    Adventure,
    Biography,
    Fiction,
    Science
}

Why separate this? These elements are often needed by multiple layers and even external clients. Keeping them in a dedicated project prevents circular dependencies.

Domain (`Acme.BookStore.Domain`)

The core business logic lives here:

Entities and aggregate roots
Repository interfaces (not implementations!)
Domain services
Domain events

public class Book : AggregateRoot<Guid>
{
    public string Name { get; set; }
    public BookType Type { get; set; }
    public DateTime PublishDate { get; set; }
}

This layer is infrastructure-agnostic — it doesn't know about databases, APIs, or UI frameworks.

Application Contracts (`Acme.BookStore.Application.Contracts`)

This project defines the application layer's public API:

Data Transfer Objects (DTOs)
Application service interfaces
Permission definitions

public interface IBookAppService : IApplicationService
{
    Task<BookDto> GetAsync(Guid id);
    Task<PagedResultDto<BookDto>> GetListAsync(GetBookListDto input);
    Task<BookDto> CreateAsync(CreateBookDto input);
}

Key benefit: This project can be shared with clients (like a Blazor WebAssembly app) without exposing implementation details.

Application (`Acme.BookStore.Application`)

Implementation of the application services:

Application service implementations
Object mapping configurations
Business workflow orchestration

public class BookAppService : ApplicationService, IBookAppService
{
    private readonly IRepository<Book, Guid> _bookRepository;

    public async Task<BookDto> GetAsync(Guid id)
    {
        var book = await _bookRepository.GetAsync(id);
        return ObjectMapper.Map<Book, BookDto>(book);
    }
}

Entity Framework Core (`Acme.BookStore.EntityFrameworkCore`)

Infrastructure layer for data access:

DbContext implementation
Repository implementations
Entity configurations
Database migrations

public class BookStoreDbContext : AbpDbContext<BookStoreDbContext>
{
    public DbSet<Book> Books { get; set; }

    protected override void OnModelCreating(ModelBuilder builder)
    {
        base.OnModelCreating(builder);
        builder.Entity<Book>(b =>
        {
            b.ToTable("Books");
            b.Property(x => x.Name).IsRequired().HasMaxLength(128);
        });
    }
}

HTTP API (`Acme.BookStore.HttpApi`)

API controllers that expose your application services:

[Route("api/books")]
public class BookController : AbpController
{
    private readonly IBookAppService _bookAppService;

    [HttpGet("{id}")]
    public Task<BookDto> GetAsync(Guid id)
    {
        return _bookAppService.GetAsync(id);
    }
}

HTTP API Client (`Acme.BookStore.HttpApi.Client`)

This is a powerful pattern — typed HTTP client proxies for consuming your API:

// Consumers can use IBookAppService directly
// The proxy handles HTTP calls transparently
var books = await _bookAppService.GetListAsync(new GetBookListDto());

This enables code sharing between server and client applications, reducing duplication and ensuring type safety.

Web (`Acme.BookStore.Web`)

The UI layer — whether Razor Pages, Blazor, or MVC:

Pages/Components
View models
Static assets
UI-specific configurations

Database Migrator (`Acme.BookStore.DbMigrator`)

A console application for:

Running database migrations
Seeding initial data
DevOps-friendly deployment scenarios (Like updating all tenant databases if you use database-per tenant approach)

Test Projects: Comprehensive Coverage

The test/ folder mirrors the source structure:

Project	Purpose
`TestBase`	Shared test infrastructure and utilities
`Domain.Tests`	Unit tests for domain logic
`Application.Tests`	Application service integration tests
`EntityFrameworkCore.Tests`	Repository and database tests
`HttpApi.Client.ConsoleTestApp`	End-to-end API testing
`Web.Tests`	UI layer tests

This structure makes it clear what you're testing and enables focused test runs during development.

Key Benefits of This Structure

1. Clear Separation of Concerns

Each project has a single, well-defined responsibility. Developers immediately know where to find and place code.

2. Dependency Inversion in Practice

The domain layer defines repository interfaces; the infrastructure layer implements them. Your business logic remains pure.

3. Shareable Contracts

The .Domain.Shared and .Application.Contracts projects can be packaged as NuGet packages and shared:

Across microservices
With client applications
With external integrators

4. Testability by Design

Each layer can be tested in isolation with appropriate mocking strategies.

5. Database Independence

Switching from SQL Server to PostgreSQL? Only the EntityFrameworkCore project needs changes.

6. Ready for Growth

This structure naturally evolves into modular monolith or microservices architectures.

Beyond Monolith: Modular and Microservice Architectures

While this article focuses on a single application structure, the same principles scale beautifully:

Modular Monolith

Microservices

Each microservice can follow this exact structure, with the .Domain.Shared and .Application.Contracts projects published as NuGet packages for inter-service communication.

ABP Framework provides comprehensive templates and guidance for both architectures. Check out the ABP Framework GitHub repository for:

Modular application templates
Microservice solution templates
Real-world sample applications

Getting Started

If you'd like to try this structure yourself, ABP Framework provides CLI tools to generate solutions with this exact architecture:

dotnet tool install -g Volo.Abp.Studio.Cli
abp new Acme.BookStore -m none --theme leptonx-lite -csf --connection-string "Server=(LocalDb)\\MSSQLLocalDB;Database=BookStore;Trusted_Connection=True;TrustServerCertificate=true"

Or, you can go to https://abp.io/get-started page and select other options like PostgreSQL, MongoDB, Angular, Blazor etc...

Conclusion

Whether you're building a simple CRUD application or an enterprise-grade distributed system, starting with a clean structure will serve you well. Happy coding!

Have questions or feedback? Feel free to open an issue on the ABP Framework GitHub repository or join our community discussions.

Why Modular Monolith Architecture is the Key to Effective AI-Assisted Development

ismail Cagdas — Tue, 06 Jan 2026 13:53:35 +0000

AI coding assistants have revolutionized how we write code. Tools like GitHub Copilot, Claude, ChatGPT, and Cursor have become indispensable companions for developers worldwide. However, there's a growing challenge that many developers are experiencing: as your codebase grows, AI-generated code quality decreases significantly.

In this article, we'll explore why this happens and how ABP Framework's modular monolith architecture provides an elegant solution to this problem.

The Problem: AI Struggles with Large Codebases

If you've been using AI coding assistants for a while, you've probably noticed a pattern. When you start a new project, AI suggestions are remarkably accurate. The code is clean, follows best practices, and integrates nicely with your existing code. But as your project grows to hundreds of files and thousands of lines of code, something changes.

Context Window Limitations

AI models have a fundamental constraint: context windows. Even the most advanced models can only process a limited amount of code at once. When your project has 500+ files with complex interdependencies, the AI simply cannot see the full picture.

Consider this scenario:

📁 MyLargeProject/
├── 📁 src/
│   ├── 📁 Domain/ (50+ files)
│   ├── 📁 Application/ (80+ files)
│   ├── 📁 Infrastructure/ (40+ files)
│   ├── 📁 HttpApi/ (60+ files)
│   └── 📁 Web/ (100+ files)
├── 📁 tests/ (150+ files)
└── 📁 shared/ (30+ files)

When you ask AI to implement a new feature, it might see only 10-20 of these files in its context. The result? Code that:

Duplicates existing functionality
Violates established patterns in your codebase
Uses inconsistent naming conventions
Creates unnecessary coupling between components
Ignores your custom base classes and utilities

The Consistency Problem

In a large monolithic codebase, there are often multiple ways to accomplish the same task. Your team might have established specific patterns over time, but the AI doesn't know about these conventions unless they're explicitly provided in the context.

// Your established pattern (which AI doesn't see)
public class ProductAppService : ApplicationService, IProductAppService
{
    private readonly IRepository<Product, Guid> _productRepository;

    public ProductAppService(IRepository<Product, Guid> productRepository)
    {
        _productRepository = productRepository;
    }

    public async Task<ProductDto> GetAsync(Guid id)
    {
        var product = await _productRepository.GetAsync(id);
        return ObjectMapper.Map<Product, ProductDto>(product);
    }
}

// What AI might generate (inconsistent with your patterns)
public class OrderService
{
    private readonly DbContext _context;

    public OrderService(DbContext context)
    {
        _context = context;
    }

    public async Task<OrderDto> Get(Guid id)
    {
        var order = await _context.Orders.FindAsync(id);
        return new OrderDto 
        { 
            Id = order.Id,
            // Manual mapping...
        };
    }
}

The AI-generated code works, but it introduces inconsistency, bypasses your repository abstractions, and ignores your mapping conventions.

The Solution: Modular Monolith Architecture

This is where ABP Framework's modular monolith architecture shines. Instead of one massive codebase, you organize your application into isolated modules.

What is a Module in ABP?

An ABP module is a independent unit that encapsulates a specific business capability:

📁 Acme.ProductManagement/
├── 📁 src/
│   ├── Acme.ProductManagement.Domain/
│   ├── Acme.ProductManagement.Domain.Shared/
│   ├── Acme.ProductManagement.Application/
│   ├── Acme.ProductManagement.Application.Contracts/
│   ├── Acme.ProductManagement.EntityFrameworkCore/
│   ├── Acme.ProductManagement.HttpApi/
│   └── Acme.ProductManagement.Web/
└── 📁 test/
    └── Acme.ProductManagement.Application.Tests/

Each module has:

Clear boundaries: Well-defined interfaces for communication with other modules
Independent domain: Its own entities, repositories, and domain services
Isolated application layer: Application services that don't leak into other modules
Focused scope: Typically 10-30 files per layer, not hundreds

How This Helps AI

When you work with AI on a modular codebase, you can scope the conversation to a single module. Instead of providing context about your entire 500-file project, you provide context about a 50-file module.

"I'm working on the ProductManagement module in an ABP Framework project.
Here's the module structure and key files:
- Product entity (Domain layer)
- IProductRepository interface
- ProductAppService (Application layer)

I need to add a feature to track product price history..."

Now the AI has:

A complete picture of the relevant code
Clear patterns to follow
Defined boundaries it shouldn't cross
Consistent conventions throughout

Benefits of Module-Scoped AI Development

1. Reduced Context Size = Better Understanding

A typical ABP module contains a focused set of files that easily fit within AI context windows:

Scope	Files	AI Understanding
Full Monolith	500+	Poor - sees fragments
Single Module	30-50	Excellent - sees everything

When AI can see your entire module, it understands:

How entities relate to each other
Which base classes and interfaces to use
Your naming conventions and patterns
The existing functionality to avoid duplication

2. ABP Conventions Guide the AI

ABP Framework follows strong conventions. When you tell AI you're working with ABP, it can leverage these conventions:

// AI understands ABP patterns and generates consistent code
public class CategoryAppService : ProductManagementAppService, ICategoryAppService
{
    private readonly ICategoryRepository _categoryRepository;

    public CategoryAppService(ICategoryRepository categoryRepository)
    {
        _categoryRepository = categoryRepository;
    }

    [Authorize(ProductManagementPermissions.Categories.Create)]
    public async Task<CategoryDto> CreateAsync(CreateCategoryDto input)
    {
        var category = new Category(GuidGenerator.Create(), input.Name);
        await _categoryRepository.InsertAsync(category);
        return ObjectMapper.Map<Category, CategoryDto>(category);
    }
}

The AI naturally:

Inherits from the correct base class
Uses the module's permission definitions
Follows the repository pattern
Uses ABP's GuidGenerator and ObjectMapper

3. Easier Code Review

When AI-generated code is confined to a module, code review becomes straightforward:

git diff --stat

 src/Acme.ProductManagement.Domain/Categories/Category.cs        | 25 +++
 src/Acme.ProductManagement.Application/Categories/CategoryAppService.cs | 45 +++
 src/Acme.ProductManagement.HttpApi/Categories/CategoryController.cs     | 30 +++
 3 files changed, 100 insertions(+)

All changes are in one module. Reviewers familiar with that module can quickly validate the code quality.

4. Sustainable and Maintainable Code

Modular code generated by AI remains maintainable because:

It follows established patterns within the module
Dependencies are explicit and limited
The code can be understood in isolation
Future AI sessions can easily pick up where you left off

Practical Tips for AI-Assisted ABP Development

Tip 1: Provide Module Context Upfront

Start your AI conversation with module context:

I'm working on an ABP Framework application.
Current module: Acme.Ordering
Module purpose: Handle customer orders and order processing

Key entities:
- Order (AggregateRoot)
- OrderLine (Entity)
- OrderStatus (Enum)

Existing services:
- IOrderRepository
- OrderManager (Domain Service)
- OrderAppService

I want to add a feature to...

Tip 2: Reference ABP Conventions Explicitly

When asking AI to generate code, mention the conventions:

Generate an Application Service for managing Shipments.
Follow ABP conventions:
- Inherit from ApplicationService
- Use IRepository<T, TKey> for data access
- Use ObjectMapper for DTO mapping
- Define permissions in ShipmentPermissions class
- Use [Authorize] attributes for permission checks

In the following versions of ABP, these instructions will be included in your project out of the box. So, AI will write better and maintainable code by following ABP standards and best practices.

Tip 3: Keep Cross-Module Communication Explicit

When your feature spans multiple modules, break it down:

Step 1: Add the event class in Ordering.Domain.Shared
Step 2: Publish the event from OrderAppService
Step 3: (Separate session) Handle the event in Shipping module

This keeps each AI session focused on one module.

Tip 4: Use Module Templates as Examples

Provide AI with examples from your existing module code:

Here's how we implement app services in this module:

[Example of existing ProductAppService]

Now create a similar service for handling Categories.

Tip 5: Validate Within Module Boundaries

After AI generates code, verify it respects module boundaries:

✅ Good: Module references only its own layers and shared contracts
❌ Bad: Direct references to other module's domain or application layers

// ❌ Bad - crossing module boundaries
using Acme.Inventory.Domain; // Direct reference to another module's domain!

// ✅ Good - using integration events or shared contracts
using Acme.Inventory.Application.Contracts; // Only reference contracts

Real-World Example: Before and After

Before: AI in a Large Monolith

Prompt: "Add a feature to apply discounts to orders"

AI Result:

Creates discount logic directly in OrderController
Duplicates validation that exists in another service
Uses direct database access instead of repositories
Ignores existing Price calculation utilities

Time spent fixing: 2 hours

After: AI with Module Focus

Prompt:

In the Acme.Ordering module, add discount support.
- Add DiscountInfo value object to Order aggregate
- Add ApplyDiscount method to Order entity
- Update OrderAppService.CreateAsync to accept discount code
- Use existing IDiscountValidator from Ordering.Domain

AI Result:

Correctly extends Order aggregate
Follows existing patterns in the module
Uses the domain service you mentioned
Generates consistent, reviewable code

Time spent fixing: 15 minutes

Conclusion

The modular monolith architecture isn't just an architectural pattern—it's becoming essential for effective AI-assisted development. As AI tools continue to evolve, codebases that are organized into clear, focused modules will get significantly better results from these tools.

ABP Framework's modular architecture, with its strong conventions, clear boundaries, and standardized patterns, creates an ideal environment for AI-assisted development:

Modules provide focused context that AI can fully understand
ABP conventions guide AI to generate consistent, framework-aligned code
Clear boundaries prevent AI from creating unwanted dependencies
Standardized patterns make AI-generated code predictable and maintainable

If you're building applications with AI assistance (and who isn't these days?), consider how your architecture affects AI code quality. Investing in a modular structure with ABP Framework pays dividends not just in traditional software engineering benefits, but in dramatically improved AI-assisted development workflows.

The future of development is human-AI collaboration. Make sure your architecture is ready for it.

To learn more about ABP Framework, visit it's documentation.

Have you experienced similar challenges with AI in large codebases? Share your experiences and tips in the comments below!

DEV Community: ismail Cagdas

Angular + ASP.NET Core: Enterprise Project Getting Started Guide

Table of Contents

Prerequisites

Approach 1 — Manual Setup

Step 1: Create the Angular App

Step 2: Create the ASP.NET Core Web API

Step 3: Configure CORS

Step 4: Set Up the Angular Proxy

Step 5: Make the First API Call

Approach 2 — Visual Studio Template

Approach 3 — ASP.NET Zero

Comparison

Common Issues and Solutions

CORS Errors

Proxy Not Working

SSL Certificate Errors

Angular CLI Version Mismatch

Next Steps

What .NET 10 LTS Means for Enterprise Applications

The Support Timeline You Need to Understand

Why .NET 10 LTS Matters for Enterprise

1. Performance That Impacts Your Bottom Line

2. Security and Compliance Acceleration

3. AI-Ready Infrastructure

4. Entity Framework Core 10: Enterprise Data Features

The Migration Decision Matrix

If You Are on .NET 9

If You Are on .NET 8 LTS

If You Are on .NET 6 or .NET 7

If You Are on .NET Framework 4.8

Tooling Requirements: The Visual Studio Question

Breaking Changes to Prepare For

WebHostBuilder and IWebHost Are Obsolete

WithOpenApi Extension Method Removed

Default Images Now Use Ubuntu

The Three-Year Runway

Conclusion: The Time to Act Is Now

A Review of AI-Assisted Development Tools and My Workflow

My AI Toolkit: A Review of Development Assistants

Vibe Kanban: The Mission Control

Claude: The Master Planner

Cursor: The Coder

Gemini: The Technical Writer

GitHub Copilot: The Dependable Backup

My AI-Powered Development Workflow

What's Next?

What's Your Workflow?

An Opinionated Solution Structure for ASP.NET Core Projects

Why Solution Structure Matters

The Root Level

Source Projects: A Layered Architecture

Domain Shared (Acme.BookStore.Domain.Shared)

Domain (Acme.BookStore.Domain)

Application Contracts (Acme.BookStore.Application.Contracts)

Application (Acme.BookStore.Application)

Entity Framework Core (Acme.BookStore.EntityFrameworkCore)

HTTP API (Acme.BookStore.HttpApi)

HTTP API Client (Acme.BookStore.HttpApi.Client)

Web (Acme.BookStore.Web)

Database Migrator (Acme.BookStore.DbMigrator)

Test Projects: Comprehensive Coverage

Key Benefits of This Structure

1. Clear Separation of Concerns

2. Dependency Inversion in Practice

3. Shareable Contracts

4. Testability by Design

5. Database Independence

6. Ready for Growth

Beyond Monolith: Modular and Microservice Architectures

Modular Monolith

Microservices

Getting Started

Conclusion

An Opinionated Solution Structure for ASP.NET Core Projects

Why Solution Structure Matters

The Root Level

Source Projects: A Layered Architecture

Domain Shared (Acme.BookStore.Domain.Shared)

Domain (Acme.BookStore.Domain)

Domain Shared (`Acme.BookStore.Domain.Shared`)

Domain (`Acme.BookStore.Domain`)

Application Contracts (`Acme.BookStore.Application.Contracts`)

Application (`Acme.BookStore.Application`)

Entity Framework Core (`Acme.BookStore.EntityFrameworkCore`)

HTTP API (`Acme.BookStore.HttpApi`)

HTTP API Client (`Acme.BookStore.HttpApi.Client`)

Web (`Acme.BookStore.Web`)

Database Migrator (`Acme.BookStore.DbMigrator`)

Domain Shared (`Acme.BookStore.Domain.Shared`)

Domain (`Acme.BookStore.Domain`)

Application Contracts (`Acme.BookStore.Application.Contracts`)

Application (`Acme.BookStore.Application`)

Entity Framework Core (`Acme.BookStore.EntityFrameworkCore`)

HTTP API (`Acme.BookStore.HttpApi`)

HTTP API Client (`Acme.BookStore.HttpApi.Client`)

Web (`Acme.BookStore.Web`)

Database Migrator (`Acme.BookStore.DbMigrator`)