### OOP
When in doubt I follow 2 simple rules which help me make the right decision

  1. [Encapsulation](http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)) and [Information hiding](http://en.wikipedia.org/wiki/Information_hiding)
  2. [Low coupling](http://en.wikipedia.org/wiki/Coupling_(computer_programming)) and [High cohesion](http://en.wikipedia.org/wiki/Cohesion_(computer_science))

So this basically means `Data + Behavior` which you already know. But it also means that it is the class's responsibility to maintain the state of its instances, that is when you instantiate an object you should get a valid object with a valid state. These principles can be easily applied to modules and layers as well.

### Validation
I can think of 2 different types of validation:

  1. [Data validation](http://en.wikipedia.org/wiki/Data_validation) (aka Input validation)
  2. Business Rules validation (your case)

As their names imply, unlike the former the latter should belong in the Domain Model containing all the business logic. Even if you use Factories and Builders to build your objects and carry out some validation there you still do it in the Domain Model. I liked the [Input Validation vs. Business Rules Validation](http://ayende.com/blog/2278/input-validation-vs-business-rules-validation) article on the subject.

Back to your question. Can [Business Rules] validation be considered as an object behavior? I would say it can but I tend to think of it as an act of maintaining an object's consistency. It's somewhat different from messages (Behavior) you send to objects in that validation is mostly hidden from the outer world and can't be triggered directly.

P.S. One way to solve your problem with "invalid" data is to have different models ([CQRS](http://martinfowler.com/bliki/CQRS.html)) for read and write with the read model having looser requirements than that of the write model.