"We must separate simple, stable data models from dynamic behavioral models" -- T. Reenskaug #readingToday  

There is another key learning that we'll carry forward from this perspective: that domain classes should be dumb. Basic domain objects represent our primordial notions of the essence of a domain entity, rather than the whole universe of processes and algorithms that burdens traditional object-oriented development as Use Cases pile up over time. If I asked you what a Savings Account object can do, you'd be wise to say that it can increase and decrease its balance, and report its balance. But if you said that it can handle a deposit, we're suddenly in the world of transactions and interactions with an ATM screen or an audit trail. Now, we've jumped outside the object and we're talking about coupling with a host of business logic that a simple Savings Account has no business knowing about. Even if we decided that we wanted to give objects business intelligence from the beginning, confident that we could somehow get it right so the interface wouldn't have to change much over time, such hopes are dashed by the fact that initial Use Cases give you a very small slice of the life-time code of a system. We must separate simple, stable data models from dynamic behavioral models.

The DCI Architecture: A New Vision of Object-Oriented Programming
by Trygve Reenskaug and James O. Coplien