I understand the difference between a rich domain model and an anemic domain model.An anemic domain model contains classes with state only i.e. the behaviour is contained in application services.  I recently asked a few questions about rich domain models.  I notice that the answerers usually (well always) appear to  suggest rich classes that contain behaviour with no or little state i.e. there are local variables (passed to methods) instead of instance variables.  They use state when they can benefit from dependency injection for testing (which is good).  Simple types like strings; decimals; integers etc are usually local variables.  My research and experience tells me that this could be because these simple types are not interfaces making them more difficult to work with from an automocking perspective.However, when I read books they seem to recommend classes with state like this once: http://www.newthinktank.com/wp-content/uploads/2012/12/Object-Oriented-Design.png (notice that the state contains simple types).  Is there a pattern name for domain models where classes contain behaviour and little or no state? Is it considered an anti pattern like the anemic domain model is: https://martinfowler.com/bliki/AnemicDomainModel.html ?Please see my question here: https://codereview.stackexchange.com/questions/164772/decimal-quantities-needed-to-meet-cost.  Would you describe RobH's answer as being rich or anemic? i.e. his class contains state and behaviour, however I would expect 'Cost' to be an instance variable.
Is there a pattern name for domain models that contain behaviour and little or no state?
c#;domain driven design;domain model
It seems like you've confused rich domain vs. anemic domain with behavior objects vs. value objects. These are not different names for the same thing. These are four very different things.Rich domains are full of business rules. It has a language of it's own that a domain expert would feel comfortable reading and expressing even if they aren't a programmer.those contrast with Anemic domains concentrate on manipulating state. They actually are rich domains in a bizarre way. But the business rules are all about updating the DB and the the domain language is SQL. That's wonderful if your domain expert is a DBA.but neither of those are the same as either of these:Behavior objects are methods that are clustered around either some state that makes them change together or simply the fact that they need to be moved around together. Some have no state at all and that's just fine. A nice handy bag of functions. What they had always better be clustered around is that they are used together. That they abstract an idea together. They should cluster around a single responsibility.  Some behavior objects cluster around business rules. Not all.those contrast withValue objects (like ints, strings, stacks, queues, lists, and pretty much anything with getters) are bags of data that generally do not care about their values. They provide methods that expose their data or measure it in some way but they carefully avoid making behavior decisions based on their data.Where you've gone wrong is you've somehow got the idea that a rich domain can't have value objects and that an anemic one can't have behavior objects. Which is just silly. Sure, using nothing but value objects makes it hard to have business rules (heck it makes it hard to do anything) but lovers of anemic domains certainly don't need to swear off behavior objects to keep their domain anemic. Is there a pattern name for domain models that contain behaviour and little or no state?Functional programming? I mean really, who told you this?