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 t

Answer 1

Old question but surprisingly still relevant today.

To my knowledge, the best (only?) book about Functional Domain Driven Design is Domain Modeling Made Functional, written by Scott Wlaschin, the author of F# for fun and profit (mentioned above).

Before diving into the book, the talk Functional Programming Design Patterns is a great summary of the concepts (Hint: there is no pattern :)

The examples are in F# but they are easy to translate into any other functional language with algebraic types (Haskell and PureScript in my case).

Answer 2

Here is an example of an idiomatic F# implementation: Domain-Driven Design With F# and EventStore

Disclaimer: I'm the author.

Answer 3

There is a new idea of using Clojure (a modern version of Lisp), which is a functional language, to create domain models. This presentation is a quite good intro (and it is also an awesome demo of HTML5).

Long story short, functional attitude is great when combined with Event Sorcing. It lets you create fully testable models very easily. And if you don't want to jump into entirely new language right now, modern C# is a quite good language to write functional-like code (at least for implementing common domain models)

Answer 4

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.