When using a functional language in domain-driven design (DDD) the actual code can often be simple enough to be used when discussing domain models with domain experts, Scott Wlaschin stated at a recent Functional Londoners Group meeting when talking about domain modelling together with functional programming using F# in real-world applications.
Scott, a .NET architect and author of Understanding Functional Programming, appreciate that functional programming may look scary for an object-oriented developer because of all the strange buzzwords like Functor, Applicative, Monads, etc., but claims they are really just unfamiliar terms. Instead, for Scott, object-oriented programming is the scary one with all its concepts, e.g. polymorphism, generics, inheritance, covariance, etc. He thinks functional programming actually is easier because it has fewer concepts to worry about, and to emphasize this he is not using any of these concepts in the examples in his presentation.
In Scott’s experience many developers believes that functional programming is good for solving problems in mathematical and scientific domains but too complicated and not suitable for common real world applications, but he thinks that F# is really good for boring, line of business application, (BLOBA) development; it is very concise, it has many conveniences to avoid boilerplate and a type system that ensures correctness.
When comparing F# and C# in domain-driven design, looking at code examples both of value object and entities, Scott argues that F# often gives much simpler code, sometimes so simple that the actual code may be used when discussing the domain model with a domain expert and reviewing the code instead of using UML diagrams or other models.
When explaining the F# type system, Scott shows how types besides being an annotation for type checking also can become a domain modelling tool and used to represent a design. Since the compiler does type checking the type system can then be regarded as compile time unit tests.
a good static type system is like having compile-time unit tests
Scott concludes with claiming that F# is low risk and a safe choice for functional-first development, his primary argument being that it's backed by Microsoft.
