Felipe Dias

Jun 1, 2023

Excellent article. It was very enlightening to see DDD from a functional perspective. But a couple of doubts now haunts me:

let's take the ClaimsPolicy v SalesPolicy duality; how would that fit in the folder structure presented? Should there be a claims and a sales folder inside src/domain and then, inside of each, the entities and operations sub-folders? Or should we keep the structure as is, but create different files (for instance, salesPolicy.entity.ts and claimsPolicy.entity.ts, along with the other respective files)?
in which layer should transactional control be? I mean, where should a commit or rollback be placed? In classical DDD, the aggregate root works as a unit-of-work boundary of some sort; but if we abandon this, who should control the transaction? Yes, the repository could take care of that, but only if it operates upon an aggregate-root-like Entity; otherwise the controller might have to use more than one repository to accomplish its task, but doing so would come with the risk of the second one failling a commit after the first one has already commited. To better illustrate what I mean, I pose the question: in the upgradeSubscription controller example, how could we rollback subscriptionRepo.update if chargeCreditCard failed? I know chargeCreditCard is not a repository in the example, but I think the question is still valid in this scenario.

Typically, I haven't had an example life Sales Policy and Claims Policy within the same domain service. At SKUTOPIA we have Sales Orders, Fulfilment Orders, and Shipments — which all seem like they could be an "order", but they're not. Each iis owned by separate domains — the shipping management domain, the fulfilment domain, and the delivery domain. Each of these are separate (but large) services.

In terms of transactional boundaries, we use events, so each event is our transaction boundary. IMO, transactions are a system-level implementation behaviour, not a business logic level implementation behaviour.

For example, the startSubscriptionUpgrade controller raises a SubscriptionUpgradeStarted event, which is saved to the database. An outbox process then proceses this event and attempts to perform this upgrade with a payment processor like Stripe.

Then if Stripe succeeds, they send us a web hook. In this case, it failed because the card was rejected. Here, we save the payload to a table with the idempotency key as a unique constraint. Then an inbox process reads this stripe message and calls failSubscriptionUpgrade. This raises a SubscriptionUpgradeFailed event.

Now, our payments team can track failure rates. Our KYC or trust and safety team can look for indicators of fraud or chargeback risks.

Rolling back a database transaction because of legitimate business events is the wrong call here. These events really occurred and your system needs to treat them like expected behaviour, not an exception.

Where DO we use transactions? Well in the above example, we use a transaction when we take a lock on the cursor. We then update the cursor position within this transaction. We want to guarantee that if an unexpected system error (not user error) occurs, then our system returns to the most recent valid state. So we rollback on thrown exception (we return all expected user outcomes).

Search Hashnode