ついに突っ込まれる。

“でも、ひが氏の言う設計ではドメインロジック ドメインモデルで1つの塊じゃないかな。
ひが氏の提唱する方法は、クラス1つ1つとしてのOOっぽさは失ってしまっているけど、
ドメインとしての単位はきちんと存在している。
digitalmorningの記事は、「ロジックをサービスに記述しろ」と読める。
いや、サービスにロジックを書くのも1つの方法になりえるかもしれないけどね。”

はてなブログ

はてなブログは、無料でしっかり書けるブログサービスです。日々の生活から感じたこと、考えたことを書き残しましょう。

hatenablog.com

ということで、ついに突っ込まれてしまいました。
そうですね。その指摘は正しいと思います。（あの私の記事、修正した方が良さそうだ…）
あの記事、かなりマジメに書いたつもりなんですが、Seasarのくだりはマズかったようです。嘘つきました。ひがさん、ごめんなさい。

あの記事あたりの真意を言っておきますと、「「データ」と「処理」あたりが総決算な記事だったりします。

データと処理

サービスや処理といった責務側面をオブジェクト指向で設計するには、どのようにすればよいのでしょうか。 責務側面と…

inoccu.com

何が言いたいのかというと、オブジェクト指向は設計としてはかなり正しいというか、いいところが凄くある。
しかし、実装となると、永続化まわりのインピーダンスミスマッチがかなり大きな影響を与えてしまって、オブジェクト指向として綺麗な状態で実装するのは、かなり難しいのではないか？
実際、自分でも色々やってみたのですが、どうも上手く行かない…。

色々考えてみると、オブジェクト指向だからといって、盲目的にデータと処理を一緒にするということに拘っているのが問題なのではないか？と思い至ったのです。
…これ以上書くと、長くなるし、先に挙げたURLと同じ内容の繰り返しになってしまうので、やめておきます。

ただ、ここ数年、オブジェクト指向設計に一気に流れて行った揺り戻しのようなことが起きて、とはいっても、昔ながらの設計に完全に戻ってしまうわけでもなく…ということになるのではないか？
例えばDIコンテナを使った開発では、トランザクション単位がサービスの単位になったりすることもあり、そうなると1つのドメインというより、いくつかの関連の密なドメインがひとまとまりになって、それを統括する1つのサービスが登場して、そこにある程度のビジネスロジックも書かれるのではないか？と思ったということなのです。（GRASPでいうところの、情報エキスパートパターンはドメインにやらせれば良いとして、コントローラーパターンはちょうどサービスに割り当てられるのではないか？）

結局長くなってしまいました。ま、言い訳です。