I don't think I could disagree with the article more strongly. I've written conditional logic trees like this and they're pretty much always better than some h

I don't think I could disagree with the article more strongly. I've written conditional logic trees like this and they're pretty much always better than some hardcoded OOP/imperative code. I think what the author might have missed is that the conditions are labels for some functional result, usually from SQL as the app checks various fields on the user's database tables. So DDD doesn't actually work with data, but filters on data. The labels are to make the intermediate steps readable by humans, like how Prolog rules/predicates work. In other words, I don't think that the article has said anything, because functional code can always be transformed to look like functions acting on conditions or conditions resulting from functions. At the end of the day, functional code is still a query composed of queries. The important part is to avoid mutable state, which would turn it back into imperative code which is hard to step through and reason about.