Functional way of implementing domain driven design

Question

I've had a lot of experience with writing domain driven applications using C#. The more applications I write the more I find that I want to take an approach that doesn't fit that well with standard C#/OO techniques:

1. I want to write as many pure functions as possible because they are really easy to test.
2. I want to write my business logic in a more declarative fashion.

So I've been looking at functional languages such as F#. After all there is no reason why domain driven design has to be implemented using OO.

I was wondering if anyone has any ideas/experience with doing Domain driven design design whilst using a functional language. Especially:

• What would a functional domain model look like?
• How would you abstract the data access layer from the domain model.

Answer 1

Disclaimer: I have only a vague knowledge about domain driven design, so the answer may not use the right terms and may be overly focused on code rather than general concepts, but here are some thoughts anyway...

The focus on understanding the domain rather than designing specific features or objects to implement them seems very natural to how people use functional programming languages in general. Very often (at least in a part of a functional application) you start by designing data structure that describes (or models) the world you're working with. The data structure is separated from the implementation, so it nicely models the domain.

A very nice example is described in paper about composing financial contracts. The example is an application for valuation (and other processing) of financial contracts. The most important thing is to create model of the contracts - what are they actually? To answer that, the authors design a data structure for describing contracts. Something like:

type Contract =    | Zero                         // No trades   | Single of string * float     // Single trade (buy something for some price)   | And of Contract * Contract   // Combine two contracts    | Until of Contract * DateTime // Contract that can be executed only until...   // (...) 

There are a few other cases, but the data structure is very simple and models a wide range of pretty complex contracts that are used in the financial industry.

Summary I think the focus on data structures that are used to model the world (and are separated from the implementation that uses them) is very close to the key concepts of DDD.