Какие слои лучше всего выделить для написания приложения?

Общая концепция многослойной архитектуры

При проектировании серверного приложения на C# я рекомендую придерживаться многослойной архитектуры (Layered Architecture), которая обеспечивает разделение ответственности, упрощает тестирование, поддержку и развитие приложения. Вот основные слои, которые я выделяю:

1. Доменный слой (Domain Layer)

Ядро приложения, содержащее бизнес-логику и правила. Этот слой не зависит от внешних факторов (БД, UI, API).

// Пример доменной сущности
public class Order
{
    public int Id { get; private set; }
    public decimal TotalAmount { get; private set; }
    public OrderStatus Status { get; private set; }
    
    public void AddItem(Product product, int quantity)
    {
        // Бизнес-правила валидации
        if (quantity <= 0)
            throw new DomainException("Quantity must be positive");
        
        // Бизнес-логика расчета
        TotalAmount += product.Price * quantity;
    }
    
    public void CompleteOrder()
    {
        if (TotalAmount == 0)
            throw new DomainException("Order cannot be empty");
        
        Status = OrderStatus.Completed;
        // Может включать domain events
    }
}

2. Слой приложения (Application Layer)

Оркестрирует выполнение бизнес-сценариев, координирует работу доменного слоя и инфраструктуры. Содержит CQRS команды/запросы или сервисы приложения.

// Пример обработчика команды (CQRS)
public class CreateOrderCommandHandler 
    : IRequestHandler<CreateOrderCommand, OrderDto>
{
    private readonly IOrderRepository _repository;
    
    public async Task<OrderDto> Handle(
        CreateOrderCommand command, 
        CancellationToken cancellationToken)
    {
        var order = new Order();
        
        // Оркестрация бизнес-логики
        foreach (var item in command.Items)
        {
            var product = await _productRepository.GetById(item.ProductId);
            order.AddItem(product, item.Quantity);
        }
        
        await _repository.AddAsync(order);
        await _repository.SaveChangesAsync();
        
        return MapToDto(order);
    }
}

3. Инфраструктурный слой (Infrastructure Layer)

Реализации внешних зависимостей: работа с БД (Entity Framework), кэширование (Redis), отправка email, интеграции со сторонними API.

// Пример репозитория
public class OrderRepository : IOrderRepository
{
    private readonly ApplicationDbContext _context;
    
    public async Task<Order> GetByIdAsync(int id)
    {
        return await _context.Orders
            .Include(o => o.Items)
            .FirstOrDefaultAsync(o => o.Id == id);
    }
    
    public async Task AddAsync(Order order)
    {
        await _context.Orders.AddAsync(order);
    }
}

4. Слой представления/API (Presentation/API Layer)

Точка входа в приложение: REST API (ASP.NET Core Web API), GraphQL, gRPC, или сообщения из очереди (RabbitMQ, Kafka).

// Пример контроллера
[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    private readonly IMediator _mediator;
    
    [HttpPost]
    public async Task<ActionResult<OrderDto>> CreateOrder(
        CreateOrderRequest request)
    {
        var command = new CreateOrderCommand
        {
            Items = request.Items,
            CustomerId = request.CustomerId
        };
        
        var result = await _mediator.Send(command);
        return CreatedAtAction(nameof(GetOrder), 
            new { id = result.Id }, result);
    }
}

5. Общий слой (Common/Shared Layer)

Переиспользуемые компоненты: утилиты, расширения, DTO, исключения, константы, которые используются в нескольких слоях.

Дополнительные рекомендации

Вариации и дополнения

• Слой доступа к данным (DAL) – иногда выделяют отдельно в рамках инфраструктуры
• Слой сервисов домена – для сложной бизнес-логики, не уместной в сущностях
• Слой кэширования – абстракция над механизмами кэширования
• Слой интеграций – для работы со внешними системами

Ключевые принципы организации

1. Зависимость внутрь – внешние слои зависят от внутренних, но не наоборот
2. Инверсия зависимостей – через абстракции (интерфейсы)
3. Тонкие контроллеры – минимум логики в API слое
4. Изоляция домена – никаких внешних зависимостей в доменном слое

Практические преимущества

• Тестируемость – каждый слой можно тестировать изолированно
• Подменяемость – легко заменить реализацию (например, БД)
• Масштабируемость – можно распределять слои между разными сервисами
• Поддержка – четкое разделение упрощает понимание кода новыми разработчиками

Такой подход соответствует Clean Architecture и Domain-Driven Design, которые стали стандартом для enterprise-приложений на C#. На практике это позволяет создавать поддерживаемые, гибкие и надежные системы, способные эволюционировать годами.