Domain Modeling Made Functional (PragProg)

[PragmaticBookshelf]

You want increased customer satisfaction, faster development cycles, and less wasted work. Domain-driven design (DDD) and functional programming is the innovative combo that will get you there. Applying the core principles of functional programming results in software designs that model real-world requirements elegantly and concisely. Examples from business domains, with code in F#, show you how to build software that is business-focused, flexible, and high quality.

Scott Wlaschin @swlaschin

Edited by Brian MacDonald @bmacdonald

You want increased customer satisfaction, faster development cycles, and less wasted work. Domain-driven design (DDD) and functional programming is the innovative combo that will get you there. Applying the core principles of functional programming results in software designs that model real-world requirements elegantly and concisely. Examples from business domains, with code in F#, show you how to build software that is business-focused, flexible, and high quality.

Model a complex domain using the F# type system, creating code that is also readable documentation. Encode business rules to create “compile-time unit tests,” and eliminate potential bugs by making illegal states unrepresentable. Discover why functional programming and DDD lead naturally to service-oriented architectures. Create a functional domain model that works with traditional databases, NoSQL, and event stores, and safely expose your domain via a website or API.

Solve real problems by focusing on real-world requirements for your software.

---

“Scott Wlaschin is one of the most important communicators in practical, applied programming today. In this book, he brings clarity and simplicity to the process of bridging the gap between requirements, customers, and concrete designs and code. Enjoy!”

–Don Syme, Researcher, Microsoft U.K.

---

• Full details: Search
• View this book’s portal and details on how to post errata and suggestions here.

Don’t forget you can get 35% off with your Devtalk discount! Just use the coupon code “devtalk.com" at checkout

[mclagett]

Just starting to read this book. Curious if there is any thought to modeling in F#, but implementing in C#? Woud like to hear thoughts on introducing F#-based domain modeling into teams largely centered around C# development.

[ed-ilyin]

Idea is to model and then use the model as is

[eterps]

@swlaschin any tips or links to resources how this applies to client side development (i.e. native [mobile] apps & SPA’s). F.i. does it make sense to share some domain model types between server and client side code when possible?

[bluezebra]

I’m experimenting with this and it seems perfectly possible. Pain points are using F# Option and F# Lists in C# when also considering C# Option from Language.Ext. Handling Discriminated Unions with ‘select case’ is usable but not ideal. Plus the constructor invariant rules will live in F#. Which can put off C# developers who don’t know F# and is quite a difficult thing to sell to the team.

I’m thinking the value for me is as design communication tool and as a fast prototyping blueprint, with which I can write unit tests to explore. But I think I’ll ultimately have to throw the F# away and rebuild as C# classes in the implementation to satisfy our engineering team who are not sold on F#.

I’d also like to hear of other people’s thoughts and experience with this approach.

[swlaschin]

F# can be transpiled to JS and there are a couple of front-end frameworks for F# (see below). And yes, sharing the domain model across back and front end is a big plus!

• The SAFE stack (using the Fable transpiler) – https://safe-stack.github.io/docs/feature-clientserver/

• WebSharper – https://developers.websharper.com/docs/v4.x/fs/features

[Gio]

@swlaschin

At the preface of the book you mention, "If the emphasis of the domain is on combining elements together to make other elements, then it’s often useful to focus on what these composition rules are (the so-called “algebra”) before focusing on the data. Domains like this are widespread, from financial contracts to graphic design tools, and the principle of “composition everywhere” makes them especially suitable for being modeled with a functional approach. Unfortunately, due to space limitations, we will not be covering these kinds of domains here.”

The design example made sense (i.e. I’m working with, say, Adobe Photoshop and I compose many small UI elements to create one large UI element), but the financial contracts one did not make sense to me. Could you elaborate on this and / or provide other examples? Thanks.

[swlaschin]

Hi Gio,

Regarding design using algebras, it’s not common to be so formal in the F# world – Haskellers and FP-Scala people like to do this more!

“Functional and Reactive Domain Modeling” (in Scala) by Debasish Ghosh covers this approach, and he has also has a video of the same name if you want to get an overview.

“Algebra” implies an algebraic structure and thus an emphasis on “laws” such as the so-called monoid or monad laws. If you don’t care about having strict laws, a similar approach in practice is simply to use a Domain Specific Language with combinators. My talk on Parser Combinators is a good introduction to the principles of combinators (also available as a blog post).

/ 1 of 2

[swlaschin]

Re the financial contracts specifically, here’s a post with a lot of good links to financial DSLs. As that post mentions, the canonical paper is Simon Peyton Jones’ “Composing Contracts: an Adventure in Financial Engineering” which represents contracts using a combinator library in Haskell. That paper doesn’t really describe a formal algebra, but it can give you an idea of what’s involved. Also Chapter 15 of Real World Functional Programming has examples with both trades and animation primitives. There’s a related talk Domain Specific Languages, the functional way and Composing Chrismas with F# - Tomas Petricek

Cheers,

Scott