DDD and FP Can’t Be Friends - Yet - Mike Sperber and Henning Schwentner - DDD Europe 2023

Domain-Driven Design Europe 2023
dddeurope.com - / ddd_eu - newsletter.dddeurope.com/ / domain-driven-design-e...
Organised by Aardling (aardling.eu/)
Henning (dedicated to DDD) and Mike (ferociously FP since the 80s) agree on all the fundamentals of software architecture, but when it comes to designing models, they can't seem to find common ground. DDD and FP folks like to congratulate themselves on how well they go together - how FP modeling techniques complement DDD models, or how DDD concepts are really FP in disguise. However, much work remains to unify these two worlds:
DDD folks like to use the ubiquitous concrete language of the application domain, whereas FP folks like abstractions and the terminology that goes with it. Mixing the two results in inconsistent or contradictory vocabulary.
While both camps prefer operation-rich models, the approaches to designing these operations are incompatible. Specifically, the OO influence of DDD tilts DDD models towards the OO idea of having the objects populating the domain be encapsulated and thus isolated, whereas in FP this encapsulation is an emergent (or not emergent) phenomenon. .
DDD’s tactical design is inherently stateful, and FP is inherently stateless. This naturally leads to very different approaches to interface design, and more importantly, to the use of types and their relationship to the ubiquitous language. Moreover, this results in fundamental differences in the division between entities and value objects. Note that this is the case even when Tactical DDD is expressed in functional languages, as the means of expression change, but the fundamental approach is the same.
Even more fundamentally, DDD focuses on modeling the domain, whereas FP focuses on the human perception of the domain - this might seem like an esoteric difference, but has pervasive practical impact. Thus, to reap the full potential of combining DDD and FP, we first need to recognize the differences. While DDD has much to teach FP about relating the domain language to the code, it can learn from FP its extensive set of techniques for turning information into data as well as the judicious use of abstraction. Henning and Mike will highlight how DDD and FP approaches to design differ, and offer possible approaches to unifying both for mutual gain and insight.
Michael Sperber is CEO of Active Group in Tübingen, Germany. Mike specializes in functional programming, and has been an internationally recognized expert in the field: He has spoken at the top conferences in programming languages, authored many papers on the subject as well as several books. Mike is one of the founders of the funktionale-programmierung.de blog, and one of the co-organizers of the BOB developer conference.
Henning loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS - Workplace Solutions. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of Domain Storytelling (Addison-Wesley, 2022), and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt” (dpunkt, 2017).

[@gdargdar91]

They are a perfect couple if you do it right.

[@JohnMcclaned]

Imagine standing on stage for an hour showing everyone you have skill issues. DDD has nothing to do with whether you use OO or FP lmao

[@FatFuckRecherche]

That was a great talk against FP for me 😁

[@thebil]

Love how stereotypically smug is the FP programmer.

[@statebased]

A bit too much emotional "junk" in this interplay. I have run both OO and FP domain modeling, what counts is the quality of the people. FP is however needed if the domain has multiple levels of interpretation.

[@PierreThierryKPH]

It's a shame to present them as opposed somehow. It's disappointing that this talk was making jokes about FP stereotypes instead of showing the reality and usefulness of FP. Like, Haskell is the best language to me when I want to to something I/O or mutation heavy, if only because I can cleanly separate where the side effects occur and where they never do.