一个交易中的多个聚合体/存储库[英] Multiple Aggregates / Repositories in one Transaction

问题描述

I have a payment system as shown below. The payment can be made through multiple gift coupons. The gift coupons are issued along with a purchase. The customer can make use of this gift coupon for future purchase.

When a Payment is made through gift coupon, the UsedForPaymentID column in GiftCoupon table need to be updated with that PaymentID (for the giftcoupon ID).

The GiftCouponIDs are already available in the database. When a customer produces a gift coupon, it has GiftCouponID printed on it. The operator need to enter this CouponID to the system to make the Payment.

For the MakePayment() operation, it necessitates two repositories.

1. Gift Coupon Repository
2. Payment Repository

CODE

//Use GiftCouponRepository to retrieve the corresponding GiftCoupon object.

This involves use of two repositories for one transaction. Is it a good practice? If not, how can we change the design to overcome this?

Reference: In DDD the Aggregate should represent the transactional boundary. A transaction that requires the involvement of more than one aggregate is often a sign that either the model should be refined, or the transactional requirements should be reviewed, or both. Is CQRS correct for my domain?

C# CODE

public RepositoryLayer.ILijosPaymentRepository repository { get; set; }

public void MakePayment(int giftCouponID)
{
    DBML_Project.Payment paymentEntity = new DBML_Project.Payment();
    paymentEntity.PaymentID = 1;

    DBML_Project.GiftCoupon giftCouponObj;

    //Use GiftCouponRepository to retrieve the corresponding GiftCoupon object.     

    paymentEntity.GiftCouponPayments = new System.Data.Linq.EntitySet<DBML_Project.GiftCoupon>();
    paymentEntity.GiftCouponPayments.Add(giftCouponObj);

    repository.InsertEntity(paymentEntity);
    repository.SubmitChanges();
}

推荐答案

I think what you really meant to ask was regarding 'Multiple Aggregates in one transaction'. I don't believe there is anything wrong with using multiple repositories to fetch data in a transaction. Often during a transaction an aggregate will need information from other aggregates in order to make a decision on whether to, or how to, change state. That's fine. It is, however, the modifying of state on multiple aggregates within one transaction that is deemed undesirable, and I think this what your referenced quote was trying to imply.

The reason this is undesirable is because of concurrency. As well as protecting the in-variants within it's boundary, each aggregate should be protected from concurrent transactions. e.g. two users making a change to an aggregate at the same time.

This protection is typically achieved by having a version/timestamp on the aggregates' DB table. When the aggregate is saved, a comparison is made of the version being saved and the version currently stored in the db (which may now be different from when the transaction started). If they don't match an exception is raised.

It basically boils down to this: In a collaborative system (many users making many transactions), the more aggregates that are modified in a single transaction will result in an increase of concurrency exceptions.

The exact same thing is true if your aggregate is too large & offers many state changing methods; multiple users can only modify the aggregate one at a time. By designing small aggregates that are modified in isolation in a transaction reduces concurrency collisions.

Vaughn Vernon has done an excellent job explaining this in his 3 part article.

However, this is just a guiding principle and there will be exceptions where more than one aggregate will need to be modified. The fact that you are considering whether the transaction/use case could be re-factored to only modify one aggregate is a good thing.

Having thought about your example, I cannot think of a way of designing it to a single aggregate that fulfills the requirements of the transaction/use case. A payment needs to be created, and the coupon needs to be updated to indicate that it is no longer valid.

But when really analysing the potential concurrency issues with this transaction, I don't think there would ever actually be a collision on the gift coupon aggregate. They are only ever created (issued) then used for payment. There are no other state changing operations in between. Therefore in this instance we don't need to be concerned about that fact we are modifying both the payment/order & gift coupon aggregate.

Below is what I quickly came up with as a possible way of modelling it

• I couldn't see how payments make sense without an order aggregate that the payment(s) belong to, so I introduced one.
• Orders are made up of payments. A payment can be made with gift coupons. You could create other types of payments, such as CashPayment or CreditCardPayment for example.
• To make a gift coupon payment, the coupon aggregates must be passed to the order aggregate. This then marks the coupon as used.
• At the end of the transaction, the order aggregate is saved with its new payment(s), and any gift coupon used is also saved.

Code:

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;
    }
}

其他推荐答案

There's nothing wrong with using two repositories in one transaction. As JB Nizet points out, that's what a service layer is for.

If you're having issue keeping the connection shared, you can use the Unit of Work¹ pattern to control the connection from the service layer and have the factory that provides the data context to your repositories supply the OoW instance.

¹ The EF/L2S DataContext is itself a UoW implementation, but it's nice to have an abstract one for the service layer for situations such as these.

其他推荐答案

The answer I would submit would be 'it depends'(tm) as it comes down to what is 'good enough'

The context of both the problem space and the technical implementation are not well known and will affect any acceptable solution.

If the technologies allow it (say in a ACID data store), then it might make sense from a business perspective to use a transaction.

If the technologies do not provide these capabilities, then it might make sense to 'lock' all the coupons and the payments records in order for the updates to be consistent. How long of a lock and what contention might be occurring would need to be investigated.

Thirdly, it could be implemented as multiple transactions/aggregates with the following rough business process strategy.

Note: I'm not defining how the interaction is happening between the aggregates as the technical requirements are not known

1. 'Create' the first aggregate (let's call it the purchase aggregate), which will record the expected payments which identify the coupon(s) to be used.
2. As late as possible, confirm that the current business policies are valid (each coupon is currently valid). If not, cancel/stop the business transaction.
3. Persist the purchase aggregate in a 'tentative' state.
4. interact with each coupon aggregate to 'adjust limit' for the tentative purchase. Reply back with success/failure.
5. the 'adjust limit' will change the available amount of money that is available for other potential purchase aggregates
6. If any of the coupons fail to 'adjust limit', then the purchase is 'being cancelled' and the coupon limits that were approved are re-adjusted back to the pre-purchase request amounts (and the purchase is now in a 'cancelled' state)
7. If all coupons limit are adjusted, then the purchase is now in an 'finalizing' state
8. in the 'finalizing' state, the system now interacts with each coupon aggregate to 'finalize coupon usage' where, possibly, the coupon usage for the purchase is journaled on the coupon aggregate (depends on business logic and need)
9. once all the coupon usages have been finalized, then the purchase aggregate is set to the state of 'approved' and any additional business processes can commence.

A lot of your choices will depend on what is correct from a business and technical capabilities perspective. The pro's and con's of each choice affect the business's success, either now or in the future. 'It depends'(tm)