> The domain model is just a data structure that reflects functional requirements, and the application is just a bunch of code that directly or indirectly opera

> The domain model is just a data structure that reflects functional requirements, and the application is just a bunch of code that directly or indirectly operates over that data structure. You are right! I learn something new every day. "Although a model-driven design does not have to be object oriented, it does depend on having an expressive implementation of the model constructs, be they objects, rules or workflows. If the available tool does not facilitate that expressiveness, reconsider the choice of tools" - Eric Evans, Domain Driven Design, Ch 5 Now although Eric specifically states that a model-based design doesn't have to follow an OO approach (he gives Prolog/Rule Engines as an alternative), the bulk of the rest of his book does demonstrate how to model a domain using OO techniques. I guess that is why I (and maybe most people) associate DDD so strongly with object oriented design. I wonder if he had written his book in 2020 he would have included functional modeling approaches along side the OO examples.