Discussion on "Functional Domain Driven Design: Simplified"

Anthony Manning-Franklin · 2022-05-01T13:45:28.497Z

Domain-Driven Design (DDD) simplifies the development and maintenance of complex software applications. However, two seminal books on the topic, Domain-Driven Design and Domain-Driven Design Distilled focus on an object-oriented implementation. How c...

Great article. This has sent me down the path of learning fp-ts along with trying to get a greater understanding of ddd/fddd. Do you have any small repositories you’d recommend to study for concrete implementations?

High-quality article, thx Anthony. I always thought DDD was the sweet-spot for OO, but your article is making me reconsider whether that is necessary. I can also see how a Functional approach could help simplify ORM issues.

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).

I have been looking for a DDD + typescript + functional article for quite awhile. Thanks for dropping this.

I do have a question, could you provide a use-case for the getMatching method in subscriptionRepository. It would help me in understand how the Query type is being used in relation to the actual sql query syntax. Thanks.

Thank you for an awesome article. I have a question about controller part.

All switch case handle deriver outcome. Do you have any idea about how to handle errors such as getting data from db, sendRepaymentReminder and so on?

I followed this fDDD pattern in my toy project and was curious about this. Thanks again for this really nice article.

If the database throws an exception, then something is seriously wrong with your application and you want to fail fast and hard. Let the exception bubble all the way up to your route handler, return 500, and log the exception.

You need to differentiate between user error and system error. User error is an outcome you want to handle and include in your type system, while a system error is an exception you want to throw. I talk about this more in antman-does-software.com/stop-catching-errors-in-…

If you mean "what if the row doesn't exist" well that's easy, have your database repo return the Entity or undefined, and have the deriver return an appropriate outcome if the result of the lookup is undefined.

(disclaimer: an opinion that nobody should really care) Awesome article! I'm recently diving into the world of functional programming and this will give me an starting point. I would say it's missing a little bit the hexagonal (ports and adapters) architecture (which gives you all the testability in the domain layer even with OOP, it's not an exclusive advantage of functional then :P), but still this gives great points and i will come back often to check this article it for sure. Thanks for writing this.

Discussion

Functional Domain Driven Design: Simplified

Responses(8)

Recent discussions

Search Hashnode

Functional Domain Driven Design: Simplified

Responses(8)

Recent discussions