ActionとServiceの統合?

これまで、Actionはプレゼンテーション層のコントローラ(コマンド)であり、Serviceはビジネスロジック層のコントローラ(ファザード)という話をしてきました。ActionはプレゼンテーションモデルをServiceに渡し、ServiceはDxoを使って、プレゼンテーションモデルをドメインモデルに変換し、ドメインモデルを実行するという流れです。Serviceのメソッドにトランザクション境界があります。
Dxoは、ビジネスロジック層にあった方がいいというのが、http://d.hatena.ne.jp/higayasuo/20050824#1124874756で書いた話です。
これは、人のスキルや役割分担という意味でも、アーキテクチャーとしてもきれいにできていると思うのですが、若干気がかりな点があります。ActionはServiceに処理を委譲しているだけであり、ほとんど働いてない点です。データアクセスしかないビジネスロジックの場合、Serviceもほとんど働いてません。
まこたんから、「DxoをActionに持っていって、トランザクション境界をActionのメソッドに持っていったら良いじゃん」という提案がありました。
これまでは、トランザクションは、ビジネスロジック層で処理すべしという固定観念があったので、ありえない考えだと思っていたのですが、なぜありえないかというと気持ち悪いという意外に急に理由を思いつけません。私の固定観念だったのかもしれません。
トランザクション境界をActionのメソッドに持っていくと、ActionとServiceを統合することが可能です。すると、長年の懸念であったデータアクセスしかしないビジネスロジックの場合に単にDaoに処理を委譲するだけのビジネスロジック層のクラスを造らなければならない問題も解決します。
Actionをプレゼンテーション層とビジネスロジック層のglue(Controler)として使うわけです。
これに対応したアーキテクチャーも考えてみます。