ついに突っ込まれる。

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

ひとりごと.class – 今日も答えは出ない~層設計~

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

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

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

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

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

この記事を書いた人

井上 研一

経済産業省推進資格ITコーディネータ/ITエンジニア/ブロガー。
井上研一事務所代表、株式会社ビビンコ代表取締役、一般社団法人ITC-Pro東京理事。
北九州市出身、横浜市在住。 AIやIoTに強いITコーディネータとして活動中。著書に「初めてのWatson」、「ワトソンで体感する人工知能」など。セミナーや研修講師での登壇も多数。

この記事が気に入ったら
いいね!しよう

最新の情報をお届けします