Clean Architecture Implementation Guide

When implementing Clean Architecture in .NET applications, follow these core principles:

Layer Separation

Domain Layer (Core Business Logic)

• Contains business entities, value objects, and domain services
• No dependencies on external frameworks or libraries
• Pure business logic without technical concerns
• Example: Entity<T>, IAggregateRoot, domain events

Application Layer (Use Cases)

• Implements use cases and application services
• Contains DTOs, interfaces, and command/query handlers
• Orchestrates domain logic but doesn't contain business rules
• Example: ICommandHandler<T>, IQueryHandler<T, TResult>

Infrastructure Layer (External Concerns)

• Database access, file system, external APIs
• Implementation of application layer interfaces
• Technical details like Entity Framework configuration
• Example: DbContext, IRepository<T>, IEmailService

Presentation Layer (API/UI)

• API endpoints, controllers, or web interfaces
• HTTP request/response handling
• Input validation and output formatting
• Example: Controllers, middleware, DTO mapping

Key Principles

Dependency Rule

• Dependencies flow inward toward the Domain
• Inner layers don't know about outer layers
• Use dependency inversion for all cross-layer communication

Business Logic Independence

• Business rules should be framework-agnostic
• No dependency on Entity Framework, ASP.NET Core, etc.
• Entities should be POCOs (Plain Old CLR Objects)

Interface Segregation

• Define interfaces in the layer that needs them
• Implement interfaces in the appropriate outer layer
• Use dependency injection for all cross-layer dependencies

Implementation Patterns

Entity Structure

// Domain Entity
public abstract class Entity<T>
{
    public T Id { get; protected set; }
    public DateTime CreatedAt { get; protected set; }
    
    // Domain logic methods
    public void Validate() { /* business rules */ }
}

// Multi-tenant entity
public abstract class MultiTenantEntity : Entity<Guid>, ITenantEntity
{
    public Guid TenantId { get; protected set; }
    
    public bool BelongsToTenant(Guid tenantId) => 
        TenantId == tenantId;
}

Repository Pattern

// Application layer interface
public interface IRepository<T> where T : Entity<Guid>
{
    Task<T> GetByIdAsync(Guid id);
    Task<IEnumerable<T>> GetAllAsync();
    Task AddAsync(T entity);
    Task UpdateAsync(T entity);
    Task DeleteAsync(Guid id);
}

// Infrastructure implementation
public class Repository<T> : IRepository<T> where T : Entity<Guid>
{
    private readonly GloboTicketDbContext _context;
    
    // Implementation with EF Core
}

Use Case Pattern

public class CreateVenueCommand : IRequest<VenueDto>
{
    public string Name { get; set; }
    public string Address { get; set; }
    public Guid TenantId { get; set; }
}

public class CreateVenueCommandHandler :
    IRequestHandler<CreateVenueCommand, VenueDto>
{
    private readonly IVenueRepository _venueRepository;
    private readonly IMapper _mapper;
    
    public async Task<VenueDto> Handle(CreateVenueCommand request)
    {
        var venue = new Venue(request.Name, request.Address, request.TenantId);
        await _venueRepository.AddAsync(venue);
        return _mapper.Map<VenueDto>(venue);
    }
}

GloboTicket Implementation

Project Structure

• GloboTicket.Domain/ - Domain entities and business logic
• GloboTicket.Application/ - Use cases, DTOs, interfaces
• GloboTicket.Infrastructure/ - EF Core, external services
• GloboTicket.API/ - Controllers, middleware, API endpoints

Tenant Context Integration

• Use ITenantContext for tenant resolution
• Enforce tenant isolation in all queries
• Include tenant validation in business logic

Configuration

• Fluent API for entity configuration
• Separate configuration classes per entity
• Proper relationship and constraint definitions

Testing Strategy

• Unit tests for domain logic (Domain layer)
• Application tests for use cases (Application layer)
• Integration tests for infrastructure (Infrastructure layer)
• API tests for endpoints (Presentation layer)

This architecture ensures maintainability, testability, and adherence to SOLID principles while providing clear separation of concerns.