tgoop.com/csharpproglib/6295
Create:
Last Update:
Last Update:
В .NET-проектах часто пишут валидацию прямо в контроллере или сервисе:
— проверили, что поле не пустое,
— число больше нуля,
— email подходит по формату.
Это правильно, но есть проблема — бизнес-правила остаются размазаны по коду.
В итоге можно случайно создать объект в некорректном состоянии (например, заказ без товаров).
В идеале должно быть два уровня валидации Application Validation И Domain Validation. В одном проверяются входные данные, а в другом строится защита сущностей от нарушения бизнес-правил.
Пример проверки на уровне приложения:
public record CreateOrderDto(string CustomerEmail, List<OrderItemDto> Items);
public class OrderApplicationValidator
{
public static void Validate(CreateOrderDto dto)
{
if (string.IsNullOrWhiteSpace(dto.CustomerEmail))
throw new ArgumentException("Email is required");
if (!dto.CustomerEmail.Contains("@"))
throw new ArgumentException("Email format is invalid");
if (dto.Items == null || dto.Items.Count == 0)
throw new ArgumentException("Order must contain at least one item");
}
}
Здесь мы проверяем только корректность ввода.
А вот внутри домена мы защищаем бизнес-правила:
public class OrderItem
{
public string ProductName { get; }
public int Quantity { get; }
public Money Price { get; }
private OrderItem(string productName, int quantity, Money price)
{
ProductName = productName;
Quantity = quantity;
Price = price;
}
public static OrderItem Create(string productName, int quantity, Money price)
{
if (string.IsNullOrWhiteSpace(productName))
throw new InvalidOperationException("Product name cannot be empty");
if (quantity <= 0)
throw new InvalidOperationException("Quantity must be greater than zero");
return new OrderItem(productName, quantity, price);
}
public Money GetTotal() => Money.Create(Quantity * Price.Amount);
}
Когда правила закреплены в домене, они становятся частью самой логики, а не зависимыми от внешних слоёв. Это гарантирует, что объект в принципе невозможно построить в некорректном виде.
#il_люминатор