状態変化するエンティティの管理はどこですべきか？

エンティティ自体が状態値をもつのが第一候補でしょうが、アプリケーションやビジネスフローのコンテキストで管理したい場合もあります。前者の例としては図書システムの貸出中などでエンティティが本質的にもつ状態値で、後者であればデータ編集処理における排他を目的とした編集中フラグなどのアプリケーションが一時的に取り扱う状態などです。
この２つの使い分けなのですが、案外頭を悩ませます。伝言モデルにおいても伝言の状態として伝言エンティティに状態値をもたせるアイデアはあるのですが、この状態値のバリエーションがアプリケーションロジック（ユースケースコントローラ）の実装にかなり依存してしまいます。ユースケースのフローで"コールバック待ち"や"確認待ち"があればそれらを状態値として扱うことになるのですが、このフローが変化すると状態値のバリエーションも変化してしまいます。状態値がエンティティではなくユースケースに強く結び付いていると考えられます。もし伝言エンティティにこの状態値の管理を行わせると伝言エンティティがアプリケーションの変更に敏感になってしまいます。今回伝言エンティティにこの状態値の管理の責務を持たせないようにした理由がこのようなところにあります。
もし、状態値によってエンティティの振る舞いが変わるような場合であればエンティティが状態管理し、エンティティの状態値が特別な機能でしかも一時的にしか利用しないようであればユースケースコントローラのコンテキストで管理するのが妥当なところと考えています。なお、本質的な状態をエンティティで管理し、アプリロジック都合でより詳細な状態をユースケースコントローラで管理するハイブリッドなケースも考えれれます。伝言メモであれば"未確認／確認済み"などの状態エンティティで管理し、ユースケースコントローラではより細かな"作成済み／コールバック待ち／完了／．．．"を導入するようなアイデアです。
いずれにしても、より良い（≒使いやすい）判断基準があればよいのですが。。。