Clean Architecture i Domain-Driven Design w Praktyce 2025

Aggregates - Consistency Boundaries

Aggregate to cluster of entities/VOs traktowanych jako unit. Aggregate Root to single entity będący entry point. Zewnętrzne obiekty mogą referencować tylko root, nie internal entities.

public class Order : Entity<OrderId>, IAggregateRoot  // Root!
{
    private readonly List<OrderItem> _items = new();  // internal entities
    public IReadOnlyCollection<OrderItem> Items => _items.AsReadOnly();

    // All modifications przez Aggregate Root
    public void AddItem(ProductId productId, int quantity, Money price)
    {
        // Aggregate enforces invariants
        if (Status != OrderStatus.Draft)
            throw new DomainException("Cannot modify confirmed order");

        var existingItem = _items.Find(i => i.ProductId == productId);
        if (existingItem != null)
            existingItem.IncreaseQuantity(quantity);  // internal call OK
        else
            _items.Add(new OrderItem(productId, quantity, price));
    }

    public void RemoveItem(OrderItemId itemId)
    {
        var item = _items.Find(i => i.Id == itemId);
        if (item == null)
            throw new DomainException("Item not found");

        _items.Remove(item);
    }
}

public class OrderItem : Entity<OrderItemId>  // Internal entity
{
    // No public constructor! Only through Order.AddItem()
    internal OrderItem(ProductId productId, int quantity, Money price)
    {
        ProductId = productId;
        Quantity = quantity;
        UnitPrice = price;
    }

    internal void IncreaseQuantity(int amount)  // internal!
    {
        Quantity += amount;
    }
}

// Repository działa na Aggregate Root
public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(OrderId id);  // loads całego aggregate
    Task AddAsync(Order order);  // saves całego aggregate
}

Domain Events - Reactive Domain Logic

Domain Event to "something happened" w domenie. Pozwala na loose coupling - jedna część domeny reaguje na zmiany w innej bez direct dependency.

// Domain Event - immutable record
public record OrderConfirmedEvent(
    OrderId OrderId,
    CustomerId CustomerId,
    Money TotalAmount,
    DateTime ConfirmedAt
) : IDomainEvent;

// Aggregate raises event
public class Order : Entity<OrderId>
{
    public void Confirm()
    {
        if (!_items.Any())
            throw new DomainException("Empty order");

        Status = OrderStatus.Confirmed;
        ConfirmedAt = DateTime.UtcNow;

        // Add event to aggregate
        AddDomainEvent(new OrderConfirmedEvent(
            Id,
            CustomerId,
            Total,
            ConfirmedAt));
    }
}

// Event Handler - może być w innym Bounded Context!
public class OrderConfirmedEventHandler
    : IDomainEventHandler<OrderConfirmedEvent>
{
    private readonly IInventoryService _inventory;
    private readonly IEmailService _email;

    public async Task Handle(OrderConfirmedEvent evt, CancellationToken ct)
    {
        // Reserve inventory (different aggregate/context)
        await _inventory.ReserveItems(evt.OrderId, ct);

        // Send confirmation email (external service)
        await _email.SendOrderConfirmation(evt.CustomerId, evt.OrderId, ct);
    }
}

Domain Events vs Integration Events: Domain Events to wewnątrz Bounded Context. Integration Events to komunikacja między kontekstami (np. przez message broker).

Domain Services

Czasem business logic nie pasuje ani do Entity, ani do Value Object. Wtedy Domain Service. Stateless operations na domain objects.

// Domain Service - logic not belonging to single entity
public class PricingService : IDomainService
{
    public Money CalculateOrderTotal(Order order, Customer customer)
    {
        var subtotal = order.Items
            .Select(i => i.UnitPrice * i.Quantity)
            .Aggregate(Money.Zero, (a, b) => a + b);

        // Complex pricing logic involving multiple aggregates
        var discount = customer.LoyaltyTier switch
        {
            LoyaltyTier.Gold => subtotal * 0.10m,
            LoyaltyTier.Silver => subtotal * 0.05m,
            _ => Money.Zero
        };

        var shipping = CalculateShipping(order, customer.Address);
        var tax = CalculateTax(subtotal - discount, customer.Address);

        return subtotal - discount + shipping + tax;
    }
}

Specifications Pattern

Reusable business rules jako obiekty. Pozwala na composition i testowanie reguł niezależnie.

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T entity);
}

public class OrderEligibleForFreeShippingSpec : ISpecification<Order>
{
    private readonly Money _threshold = new(100, "USD");

    public bool IsSatisfiedBy(Order order)
    {
        return order.Total >= _threshold;
    }
}

public class OrderFromPremiumCustomerSpec : ISpecification<Order>
{
    public bool IsSatisfiedBy(Order order)
    {
        return order.Customer.LoyaltyTier == LoyaltyTier.Gold;
    }
}

// Composition
var freeShippingSpec = new OrderEligibleForFreeShippingSpec()
    .Or(new OrderFromPremiumCustomerSpec());

if (freeShippingSpec.IsSatisfiedBy(order))
    order.ApplyFreeShipping();

Architecture Tests

Wymuś dependency rules automatycznie. ArchUnitNET (.NET) lub ts-arch (TypeScript) walidują, że Infrastructure nie leaks do Domain.

// ArchUnitNET - enforce Clean Architecture rules
[Test]
public void Domain_ShouldNotDependOn_Infrastructure()
{
    var domain = Types().That().ResideInNamespace("Domain");
    var infrastructure = Types().That().ResideInNamespace("Infrastructure");

    var rule = domain.Should().NotDependOnAny(infrastructure);

    rule.Check(Architecture);
}

[Test]
public void Domain_ShouldNotDependOn_Application()
{
    var domain = Types().That().ResideInNamespace("Domain");
    var application = Types().That().ResideInNamespace("Application");

    domain.Should().NotDependOnAny(application).Check(Architecture);
}

[Test]
public void Controllers_ShouldNotDependOn_Domain()
{
    // Controllers should only depend on Application (MediatR)
    var controllers = Types().That().ResideInNamespace("Presentation.Controllers");
    var domain = Types().That().ResideInNamespace("Domain");

    controllers.Should().NotDependOnAny(domain).Check(Architecture);
}

Czym jest Clean Architecture i dlaczego warto ją stosować?

Clean Architecture to wzorzec architektoniczny zaproponowany przez Roberta C. Martina (Uncle Bob), który separuje logikę biznesową od szczegółów technicznych. Największa korzyść? Twoja aplikacja nie jest zakładnikiem frameworka czy bazy danych. Zmiana z PostgreSQL na MongoDB, z REST API na GraphQL, z Angular na React - wszystko to możliwe bez przepisywania logiki biznesowej. Szczególnie opłaca się w projektach długoterminowych, gdzie wymagania się zmieniają, a zespół musi szybko wprowadzać nowe funkcjonalności bez ryzyka "rozwałenia" całego systemu.

Jaka jest różnica między Clean Architecture a Hexagonal Architecture?

Prawda jest taka, że różnice są minimalne - to dwa podejścia do tego samego problemu. Hexagonal Architecture (znana też jako Ports & Adapters) powstała wcześniej i używa metafory portów (interfejsy wejścia/wyjścia) oraz adapterów (ich implementacje). Clean Architecture przyszła później i nazwała warstwy wprost: Domain, Application, Infrastructure, Presentation. W praktyce? Implementujesz to samo - izolujesz logikę biznesową od zewnętrznych zależności. Wybierz tę nazwę, która lepiej brzmi w Twoim zespole.

Czym się różni tactical DDD od strategic DDD?

To jak różnica między planem miasta a projektem budynku. Strategic DDD to patrzenie na system z lotu ptaka - definiujesz Bounded Contexts (granice między modułami), Context Mapping (jak te moduły się komunikują), Ubiquitous Language (wspólny język z biznesem). Tactical DDD to schodzenie na poziom kodu - Aggregates, Entities, Value Objects, Domain Events. Najczęstszy błąd? Ludzie zaczynają od tactical patterns i tworzą piękne Aggregates... które nie mają sensu biznesowego, bo nikt nie zdefiniował granic kontekstów. Zawsze zacznij od strategic - to fundament, na którym budujesz tactical patterns.

Kiedy stosować CQRS z Clean Architecture?

CQRS to rozdzielenie operacji zapisu od odczytu - osobny model do tworzenia zamówień, osobny do ich wyświetlania. Warto, gdy masz asymetrię: dużo odczytów, mało zapisów (albo odwrotnie), złożone raporty wymagające denormalizacji, lub różne wymagania skalowania dla read/write. Przykład? E-commerce: zapisujesz zamówienie do znormalizowanej bazy, ale dashboard wymaga agregacji z 10 tabel - CQRS pozwala mieć osobny, zdenormalizowany read model tylko do raportów. NIE stosuj dla prostego CRUD - to overengineering. Jeśli formularz edycji wygląda tak samo jak widok szczegółów, CQRS to za dużo.

Clean Architecture vs Vertical Slice - który wybrać?

To zależy od charakteru aplikacji. Clean Architecture sprawdza się, gdy masz wspólną logikę biznesową wykorzystywaną w wielu miejscach - np. system finansowy, gdzie reguły walidacji czy obliczeń są reużywane. Vertical Slice Architecture jest lepsza dla aplikacji, gdzie każda funkcja jest praktycznie niezależna - panel administracyjny, backoffice, gdzie każda sekcja to osobny świat. Moja rekomendacja? Zacznij od Clean Architecture dla core domain (gdzie jest prawdziwa logika), a Vertical Slices dla supporting/generic features. I pamiętaj - możesz je łączyć: Vertical Slices na poziomie Application Layer, ale ze wspólnym Domain Layer.