Functional programming and domain-driven design might not seem to be a good match, but in fact functional programming can be an excellent approach to designing decoupled, reusable systems with a rich domain model. This workshop will show you why.

This will be a hands-on workshop designed for beginners in F#. We'll do lots of domain modeling exercises starting with some simple models and then enhancing them with constraints, state machines, error handling, commands and events, and so on.

We'll cover these topics in detail:

• The core concepts of functional programming and how they can be applied to Domain Driven Design
• How to represent the nouns and verbs of a domain ("the ubiquitous language") using types.
• Why representing the domain model using types is better than most other documentation (hint: it can never get out of sync)
• How to capture constraints and business rules in the domain model itself instead of being buried in the implementation
• How to represent state transitions
• How to treat errors as a part of the domain
• How to build a complete business workflow from smaller components using composition

Requirements:

• F# should be installed! fsharp.org has installation instructions for most operations systems.
• If using VS Code, have Ionide installed.

The techniques and patterns used in functional programming are very different from object-oriented programming, and when you are just starting out it can be hard to know how they all fit together.

In this talk for F# beginners, I'll present the most common tools that can be found in a functional programmer's toolkit: tools such as "compose", "reduce", "map", "return", "apply", and "bind". What are they? Why are they important? How are they used in practice? And how do they relate to computation expressions and scary sounding concepts like monoids, monads, and functors?

Statically typed functional programming languages encourage a very different way of thinking about types. The type system is your friend, not an annoyance, and can be used in many ways that might not be familiar to OO programmers.

Types can be used to represent the domain in a fine-grained, self documenting way. And in many cases, types can even be used to encode business rules so that you literally cannot create incorrect code. You can then use the static type checking almost as an instant unit test — making sure that your code is correct at compile time.

In this talk, we'll look at some of the ways you can use types as part of a domain driven design process, with some simple real world examples in F#. No jargon, no maths, and no prior F# experience necessary.