オブジェクト指向におけるドメイン貧血症問題についての疑問

Question

お世話になります。初めての質問なので、もし至らない点がございましたご指摘いただけると大変助かります。

前提

5年程SEとしてJavaで金融系のシステム開発をしてきました。
最近ではSpring及びTerasoluna等のフレームワークを利用して開発をする機会も増えてきました。
その中で、どうしてもオブジェクト指向についての疑問が解決できない点があり、質問させていただきます。

疑問

今まで開発していた業務システムのほぼ全てが、ビジネスロジックとドメインオブジェクトは切り離されており、世間でいう"ドメイン貧血症"が多数見受けられました。
どう考えても"ドメインオブジェクトに状態と振る舞いを持たせる"とあるオブジェクト指向とはかけ離れていると思うのですが、これは許容されるべき事象なのでしょうか。
もしくはそもそもの考え方が間違っているのでしょうか。
※ここでいう"ドメイン貧血症"とはprivateなfieldとgetter/setterのみを持つようなドメインオブジェクトを指します
※フレームワークや共通ライブラリなどのDBと関わらない部分は除きます

捕捉情報

オブジェクト指向の重要性について新人の頃から色々な人に言われ少しずつ勉強してきました。
その中で、オブジェクト指向の基本として、”ドメインオブジェクトに状態と振る舞いを持たせる”と学びました。
しかしながら実際の業務システムでは、ビジネスロジックを束ねるサービス等があり、ドメインオブジェクトは状態のみをもつオブジェクトでしかないというのがほぼ全てでした。
一方、現状この作りで問題なく稼働しているシステムもあり、またこの問題について疑問を呈する人もいませんでした。
また、Terasolunaでは"本ガイドラインでは主に、状態のみもつモデルを扱う"と明記されており、実際サンプルもそのような作りになっております。
オブジェクト指向のSOLID原則や3大要素でも"ドメインオブジェクトに状態と振る舞いを持たせる"ことは明記されていないように見受けられ、そもそも必須な要素ではないのかとも考えています。

Comments

[退会済みユーザー]

私も質問者さんと同じ疑問を抱えています。ので回答はできません。思えばJavaBeansが出た頃からおかしくなった？ような気がします。ただ、ある程度以上の規模になり、人数が増えてしまうと、ボーダーラインが下がってしまい、現実的には破綻しちゃうものなのかなとは思います。

Answer 1

どう考えても"ドメインオブジェクトに状態と振る舞いを持たせる"とあるオブジェクト指向とはかけ離れていると思うのですが、これは許容されるべき事象なのでしょうか。

アーキテクチャについて誰がどんな理由で許容する/しないというのはそのプロジェクトの要件次第です。
そのため、そのプロジェクトで問題が起きていない or 起きても何らかの方法でリカバー出来るという判断がされているのであれば許容されるべきと言わざるを得ません。
（金融系であれば作りとしてはイケていても、誰も試した事が無い様な設計は計算しきれないリスクがあるので避けたいという方針であるような気がします。
過去の成果物との設計的な整合性を取る必要もあるでしょうし）

---

質問内容がこういう設計はイケていないと思うのですがどうですか？という質問であれば(そうであれば質問を編集してください。teratail的には非推奨の質問になると思いますが)、
イケて無いし保守大変そうだなあ
という回答になります。

---

オブジェクト指向的に正しい、イケている設計や実装をしたいのであれば、それを基準として業界や所属企業の変更を考えても良いかもしれませんね。