ABP Dependency Rules

Core Principles (All Templates)

These principles apply regardless of solution structure:

1. Domain logic never depends on infrastructure (no DbContext in domain/application)
2. Use abstractions (interfaces) for dependencies
3. Higher layers depend on lower layers, never the reverse
4. Data access through repositories, not direct DbContext

Layered Template Structure

Note: This section applies to layered templates (app, module). Single-layer and microservice templates have different structures.

Domain.Shared    → Constants, enums, localization keys
       ↑
    Domain       → Entities, repository interfaces, domain services
       ↑
Application.Contracts → App service interfaces, DTOs
       ↑
  Application    → App service implementations
       ↑
   HttpApi       → REST controllers (optional)
       ↑
     Host        → Final application with DI and middleware

Layered Dependency Direction

Critical Rules

❌ Never Do

csharp
1// Application layer accessing DbContext directly
2public class BookAppService : ApplicationService
3{
4    private readonly MyDbContext _dbContext; // ❌ WRONG
5}
6
7// Domain depending on application layer
8public class BookManager : DomainService
9{
10    private readonly IBookAppService _appService; // ❌ WRONG
11}
12
13// HttpApi depending on Application implementation
14public class BookController : AbpController
15{
16    private readonly BookAppService _bookAppService; // ❌ WRONG - Use interface
17}

✅ Always Do

csharp
1// Application layer using repository abstraction
2public class BookAppService : ApplicationService
3{
4    private readonly IBookRepository _bookRepository; // ✅ CORRECT
5}
6
7// Domain service using domain abstractions
8public class BookManager : DomainService
9{
10    private readonly IBookRepository _bookRepository; // ✅ CORRECT
11}
12
13// HttpApi depending on contracts only
14public class BookController : AbpController
15{
16    private readonly IBookAppService _bookAppService; // ✅ CORRECT
17}

Repository Pattern Enforcement

Interface Location

csharp
1// In Domain project
2public interface IBookRepository : IRepository<Book, Guid>
3{
4    Task<Book> FindByNameAsync(string name);
5}

Implementation Location

csharp
1// In EntityFrameworkCore project
2public class BookRepository : EfCoreRepository<MyDbContext, Book, Guid>, IBookRepository
3{
4    // Implementation
5}
6
7// In MongoDB project
8public class BookRepository : MongoDbRepository<MyDbContext, Book, Guid>, IBookRepository
9{
10    // Implementation
11}

Multi-Application Scenarios

When you have multiple applications (e.g., Admin + Public API):

Vertical Separation

MyProject.Admin.Application      - Admin-specific services
MyProject.Public.Application     - Public-specific services
MyProject.Domain                 - Shared domain (both reference this)

Rules

• Admin and Public application layers MUST NOT reference each other
• Share domain logic, not application logic
• Each vertical can have its own DTOs even if similar

Enforcement Checklist (Layered Templates)

When adding a new feature:

1. Entity changes? → Domain project
2. Constants/enums? → Domain.Shared project
3. Repository interface? → Domain project (only if custom queries needed)
4. Repository implementation? → EntityFrameworkCore/MongoDB project
5. DTOs and service interface? → Application.Contracts project
6. Service implementation? → Application project
7. API endpoint? → HttpApi project (if not using auto API controllers)

Common Violations to Watch