Domain Entities

Main concern of entities should be keeping track of business state - that's enough of a responsibility and they shouldn't be concerned with validation. ...

[W]hether an entity is "valid" depends on its state and its context. George Polevoy points this out nicely in his answer and I share his opinion.

 Marijn - http://stackoverflow.com/questions/5818898/where-to-put-global-rules-validation-in-ddd

The above appears to contrast with the following advice:

Also your example seems to imply that your object can exist in an invalid state, this should be avoided, your domain object should always be in a valid state.

Kdeveloper - http://programmers.stackexchange.com/questions/70734/ddd-a-rookies-unanswered-questions

Oder is both a noun and a verb. The "Order" is the object that created as a result of "Ordering". Like any good class, it has both data and behavior (and I don't mean getters and setters). The behavior is the dynamic process that goes with the data, i.e., the ordering workflow. "Order" is the controller.

Doug Knesek -  http://stackoverflow.com/questions/1468218/domain-driven-design-where-does-the-workflow-logic-lie

 When a domain object begins to contain too many responsibilities, we start to break out those extra responsibilities into things like value objects and domain services.

 http://lostechies.com/jimmybogard/2010/03/30/strengthening-your-domain-the-double-dispatch-pattern/