トランザクションスクリプトとドメインモデル

このネタについては、ループしやすく結論が出ないので、あまり書きたくはないのですが、私の考えを誤解している人が多いようなので、書いておきます。
トランザクションスクリプト、ドメインモデルなんてのは、所詮実装の話で、どっちもどっち。トランザクションスクリプトが良いわけでもないし、ドメインモデルが良いわけでもない。私はどっちも好きではない。
重要なのは、ユースケース(ユーザ要件)と実装の対応関係が明確になっていることです。それさえ満たされていれば、実装はどうなっていてもかまわない。
ユースケースと実装の対応関係を明確にする方法の一つとして、ユーザ機能レベルのユースケースは、Teedaでいうサブアプリケーション(関連する複数の画面を束ねたもの)にマッピングする。サブアプリケーションは、関連する各画面の親クラスに相当する。各画面は、サブ機能レベルのユースケースに相当し、サブ機能レベルのユースケースは、Pageクラスにマッピングする。
各画面で閉じているロジックは、Pageクラスで実装する。同一ユースケース内の複数の画面で共通に使われるロジックは関連する各画面の親クラスで実装する。複数のユースケースで共通に用いられるロジックは、サブ機能レベルの共通のユースケースとして抽出し、そのクラスで実装する。
この基準でクラスを抽出すると、Page、Pageの親、共通のサービスクラスが登場します。それぞれのクラスで直接ロジックを実装しても良いし、Entityに処理を委譲してもかまわない。
このやり方は、トランザクションスクリプトでもドメインモデルでもない。別に私のオリジナルというつもりもないし、そういうことはどうでも良い。
重要なのは、ユースケースと実装の対応関係が明確になっていることです。
ドメインモデルが、本質的に優れているけど、うまく扱える技術者が少ないからあまり使われていないというのも「きっと間違い」。本質的に優れているなら、誰でも簡単に理解できて実践できるはずです。ドメインモデルは、オブジェクト指向っぽくみえるから、良いと思い込んでいるだけ。ドメインモデルはユースケースをどのように実装すればよいのかが明確ではない。開発者の経験やセンスに極端に依存するというのが、良いとはどうしても思えない。
開発プロセスだって、プロマネの経験やセンスに依存してよいわけがない。だから、CMMIのようにルールを決めて、測定して改善していくわけです。
ドメインモデルはルールが明確ではないので、良いとは思えない。本来あるべきモデルってのも蜃気楼のようなもので、そんなのないんじゃないの。だって誰もこれが本来あるべきモデルって決められないし。
わかっているのは、ユースケースだけ。ユースケース自身も正しいかどうかわからないので、ヒアリングしたり、モックを作ってイメージさせたりしながら、その精度を高めていく必要があります。本来やるべきことはそういうことだと思うな。ドメインモデルを試行錯誤することではなく。