MVCのMんところ - 売り切れました

うーん

はっきりいって、ロジックをModelに書こうがControllerに書こうが、整合性の考慮漏れは、どうしても出てきます。Modelに書いたからといって、Controllerに書いていたときの考慮漏れが自動的に解決することはないのです。
えせMVCについてそろそろ一言言っておくか - yvsu pron. yas

　これは、あるオブジェクトであるModelが単体ではシステム状態の整合性を保証できないように設計されているという事であって、スレッドセーフではないメソッドと同様に、只単に「あまり良くない設計である」というだけの事じゃないだろうか？

　なので、本人も

Serviceは永続化されないModelなので、カテゴリはModelです。
えせMVCについてそろそろ一言言っておくか - yvsu pron. yas

　と、一連のModel利用をServiceという形でwrapしてるんじゃないかと思う。
　であれば、元エントリの

ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し
October 2009 - Life is beautiful

　であって、結局は言いたいことは同じ事だろう。

　特に、オブジェクト指向が強い言語でModelを厳密に定義していくと、自然にDSLに近づいて行く事になるので、行き着くところは「特殊言語を使ってWebアプリケーションを記述する」問題になる。
　じゃぁ、その特殊言語における「ビジネスロジック」ってどこに書くの？　と。　Controllerでいいんだっけ？

　おそらくはユースケースに導き出された上で、データストア（RDBとは限らない）の制約（トランザクション）を満たすようにいくつかのWrapperとして書くのがベターじゃないだろうか。