Wiele agregatów / repozytoriów w jednej transakcji

Myślę, że naprawdę chciałeś zapytać o " Wiele agregatów w jednej transakcji ". Nie wierzę, że jest coś złego w używaniu wielu repozytoriów do pobierania danych w transakcji . Często podczas transakcji agregat będzie potrzebował informacji z innych agregatów, aby podjąć decyzję o tym, czy zmienić stan lub jak go zmienić. W porządku. Jest to jednak modyfikacja stanu na wielu agregatach w ramach jednej transakcji, która jest uważana niepożądane, i myślę, że to, co cytat próbował sugerować.

Ochrona ta jest zazwyczaj uzyskiwana poprzez umieszczenie znacznika wersji/czasu w tabeli dB agregatów. Po zapisaniu agregatu dokonuje się porównania wersji zapisywanej i aktualnie przechowywanej w bazie danych (która może być inna niż w momencie rozpoczęcia transakcji). Jeśli nie pasują one wyjątek jest podniesiony.

Sprowadza się to zasadniczo do tego: w systemie współpracy (wielu użytkowników dokonujących wielu transakcji), im więcej agregatów, które są modyfikowane w jednej transakcji, spowoduje wzrost WYJĄTKÓW w współbieżności.

Dokładnie to samo jest prawdą, jeśli Agregat jest zbyt duży i oferuje wiele metody zmiany stanu; wielu użytkowników może modyfikować agregat tylko jeden na raz. Projektując małe agregaty, które są modyfikowane osobno w transakcji, zmniejsza kolizje współbieżności.

Vaughn Vernon wykonał świetną robotę wyjaśniając to w swoim 3-częściowym artykule.

Jest to jednak tylko zasada przewodnia i będą wyjątki, w których więcej niż jeden agregat będzie musiał zostać zmodyfikowany. Fakt, że rozważasz, czy transakcja / korzystanie przypadek może być ponownie uwzględniony, aby zmodyfikować tylko jeden agregat to dobra rzecz.

Myśląc o twoim przykładzie, nie mogę wymyślić sposobu zaprojektowania go do jednego agregatu, który spełnia wymagania przypadku transakcji / użycia. Należy utworzyć płatność, a kupon należy zaktualizować, aby zaznaczyć, że nie jest już ważny.

Ale naprawdę analizując potencjalne problemy z współbieżnością z tą transakcją , nie sądzę, aby kiedykolwiek doszło do kolizja na kupon upominkowy. Są one tylko tworzone (wydawane) , a następnie wykorzystywane do płatności. Nie ma innych operacji zmieniających stan pomiędzy. Dlatego w tym przypadku nie musimy martwić się o to, że modyfikujemy zarówno płatność / zamówienie, jak i kupon upominkowy.

Poniżej jest to, co szybko wymyśliłem jako możliwy sposób modelowania tego

• nie mogłem zrozumieć, w jaki sposób płatności mają sens bez agregatu zamówienia, do którego należą płatności, więc przedstawiłem jednego.
• zamówienia składają się z płatności. Płatność może być dokonana za pomocą kuponów upominkowych. Możesz tworzyć inne rodzaje płatności, takie jak płatność gotówkowa lub Płatność kartą kredytową.
• aby dokonać płatności kuponem upominkowym, Agregaty kuponów muszą zostać przekazane do agregatu zamówienia. Oznacza to, że kupon jest używany.
• Po zakończeniu transakcji agregat zamówienia jest zapisywany wraz z nową płatnością(nowymi płatnościami), a każdy wykorzystany kupon upominkowy jest również uratowany.

Kod:

public class PaymentApplicationService
{
    public void PayForOrderWithGiftCoupons(PayForOrderWithGiftCouponsCommand command)
    {
        using (IUnitOfWork unitOfWork = UnitOfWorkFactory.Create())
        {
            Order order = _orderRepository.GetById(command.OrderId);

            List<GiftCoupon> coupons = new List<GiftCoupon>();

            foreach(Guid couponId in command.CouponIds)
                coupons.Add(_giftCouponRepository.GetById(couponId));

            order.MakePaymentWithGiftCoupons(coupons);

            _orderRepository.Save(order);

            foreach(GiftCoupon coupon in coupons)
                _giftCouponRepository.Save(coupon);
        }
    }
}

public class Order : IAggregateRoot
{
    private readonly Guid _orderId;
    private readonly List<Payment> _payments = new List<Payment>();

    public Guid OrderId 
    {
        get { return _orderId;}
    }

    public void MakePaymentWithGiftCoupons(List<GiftCoupon> coupons)
    {
        foreach(GiftCoupon coupon in coupons)
        {
            if (!coupon.IsValid)
                throw new Exception("Coupon is no longer valid");

            coupon.UseForPaymentOnOrder(this);
            _payments.Add(new GiftCouponPayment(Guid.NewGuid(), DateTime.Now, coupon));
        }
    }
}

public abstract class Payment : IEntity
{
    private readonly Guid _paymentId;
    private readonly DateTime _paymentDate;

    public Guid PaymentId { get { return _paymentId; } }

    public DateTime PaymentDate { get { return _paymentDate; } }

    public abstract decimal Amount { get; }

    public Payment(Guid paymentId, DateTime paymentDate)
    {
        _paymentId = paymentId;
        _paymentDate = paymentDate;
    }
}

public class GiftCouponPayment : Payment
{
    private readonly Guid _couponId;
    private readonly decimal _amount;

    public override decimal  Amount
    {
        get { return _amount; }
    }

    public GiftCouponPayment(Guid paymentId, DateTime paymentDate, GiftCoupon coupon)
        : base(paymentId, paymentDate)
    {
        if (!coupon.IsValid)
            throw new Exception("Coupon is no longer valid");

        _couponId = coupon.GiftCouponId;
        _amount = coupon.Value;
    }
}

public class GiftCoupon : IAggregateRoot
{
    private Guid _giftCouponId;
    private decimal _value;
    private DateTime _issuedDate;
    private Guid _orderIdUsedFor;
    private DateTime _usedDate;

    public Guid GiftCouponId
    {
        get { return _giftCouponId; }
    }

    public decimal Value
    {
        get { return _value; }
    }

    public DateTime IssuedDate
    {
        get { return _issuedDate; }
    }

    public bool IsValid
    {
        get { return (_usedDate == default(DateTime)); }
    }

    public void UseForPaymentOnOrder(Order order)
    {
        _usedDate = DateTime.Now;
        _orderIdUsedFor = order.OrderId;
    }
}