Unanimous laughter followed. Buried inside the laughter was the comment, "DDD? What is this, 2008?"
I assumed that I was missing something and that the concepts of DDD were incompatible with FP because all of the core "things" described in DDD have the word "object" in their name. But, while DDD as described by Eric Evans is implemented in an Object Oriented language in his book, it isn't implied by the fundamental approach.
Then, I stumbled on this video which hypothesizes that DDD is even better with FP. The speaker asserts that there isn't any reason Functional Programs can't also contain a "ubiquitous language", "bounded contexts", etc.
He doesn't exactly prove the hypothesis. But I assert that DDD, by my definition, is compatible with FP. So, below is my attempt to map each DDD buzzword to something that is easy to implement in a Functional program.
Value Objects - Immutable Values are all Value Object in FP.
Entities - Giving a Value Object a specific ID makes it an Entity. Easy in FP.
Aggregate - A collection. Functional program is full of these.
Aggregate Root - A function that maps over an Aggregate. I suppose we can use types to protect our Aggregates from external mutation, but this wouldn't be a necessary if we kept all of our data immutable.
Domain Event - Fans of Big Data will likely find the concept of mapping and reducing over raw data, a very Functional idiom.
Service - Functions that operate on data could be considered services.
Repository - In the process of isolating non-pure database access from pure functional code, programmers often use some sort of repository pattern to abstract the database access behind a composable API.
What does this mean? It means that we OO expats, shouldn't throw out everything we were doing to organize our domain. We should be taking the most important and useful OO tools with us as we assimilate into our new FP world and only deviate once we have proven a superior idiom is available to solve our problems.