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.
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.
(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.
Sensibo
Sensibo
good