Skip to main content

abp-dependency-rules

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

소스 정보

저장소
abpframework/abp
최근 소스 활동
2026년 3월 22일 17:13
감지된 SKILL.md 언어
영어
스타
14,437
포크
3,722

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
abp-dependency-rules
description
ABP project layer dependency rules - which projects can reference which, domain/application/infrastructure separation, cross-layer violations to avoid. Use when reviewing project structure, adding new project references, or checking if a dependency direction is correct.
# 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 ```csharp // 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 ```csharp // 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 ```csharp // In Domain project public interface IBookRepository : IRepository<Book, Guid> { Task<Book> FindByNameAsync(string name); } ``` ### Implementation Location ```csharp // 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 |
GitHub에서 보기