abp-dependency-rules

name	abp-dependency-rules
license	UNLICENSED
description	Use when reviewing project structure, adding new project references, or checking if a dependency direction is correct. Covers ABP project layer dependency rules, which projects can reference which, domain/application/infrastructure separation, and cross-layer violations to avoid.

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

Project	Can Reference	Referenced By
Domain.Shared	Nothing	All
Domain	Domain.Shared	Application, Data layer
Application.Contracts	Domain.Shared	Application, HttpApi, Clients
Application	Domain, Contracts	Host
EntityFrameworkCore/MongoDB	Domain	Host only
HttpApi	Contracts only	Host

Critical Rules

❌ Never Do

// Application layer accessing DbContext directly
public class BookAppService : ApplicationService
{
    private readonly MyDbContext _dbContext; // ❌ WRONG
}

// Domain depending on application layer
public class BookManager : DomainService
{
    private readonly IBookAppService _appService; // ❌ WRONG
}

// HttpApi depending on Application implementation
public class BookController : AbpController
{
    private readonly BookAppService _bookAppService; // ❌ WRONG - Use interface
}

✅ Always Do

// Application layer using repository abstraction
public class BookAppService : ApplicationService
{
    private readonly IBookRepository _bookRepository; // ✅ CORRECT
}

// Domain service using domain abstractions
public class BookManager : DomainService
{
    private readonly IBookRepository _bookRepository; // ✅ CORRECT
}

// HttpApi depending on contracts only
public class BookController : AbpController
{
    private readonly IBookAppService _bookAppService; // ✅ CORRECT
}

Repository Pattern Enforcement

Interface Location

// In Domain project
public interface IBookRepository : IRepository<Book, Guid>
{
    Task<Book> FindByNameAsync(string name);
}

Implementation Location

// In EntityFrameworkCore project
public class BookRepository : EfCoreRepository<MyDbContext, Book, Guid>, IBookRepository
{
    // Implementation
}

// In MongoDB project
public class BookRepository : MongoDbRepository<MyDbContext, Book, Guid>, IBookRepository
{
    // Implementation
}

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

Violation	Impact	Fix
DbContext in Application	Breaks DB independence	Use repository
Entity in DTO	Exposes internals	Map to DTO
IQueryable in interface	Breaks abstraction	Return concrete types
Cross-module app service call	Tight coupling	Use events or domain