「データクラス」は実際にコードのにおいですか？

Question

Fowlerの本Refactoringはコード臭として "データクラス"をリストしています。しかし、メソッドをユニットテストするときに、値オブジェクトを渡します。クラス内の状態を設定したり調べたりするよりもはるかに簡単にテストを行うことができます。

テスト駆動型開発方法論は、テストを書くのが簡単であるということは、インターフェイスがきれいであり、その方法が結束しているという考え方に依存していると私は思います。純粋に等価のメソッドは、テストするのが最も簡単で、再利用するのが最も簡単です。では、なぜデータクラスが悪いのですか？推奨される修正は、ビヘイビアをデータクラスに移すことですが、なぜ値オブジェクトにビヘイビアが必要なのでしょうか？

Answer 1

データクラスが値オブジェクトと同じではないと思います。値オブジェクトは通常、長さや金額のように不変です。 Fowlerが参照する 'データクラス'は、貧血ドメインモデル、つまりgetterとsetterの袋のように見えます。

したがって、値オブジェクトをメソッドに渡すことはできますが、貧弱なドメインモデルは間違いありません。これは、メソッドが複数のものを変更するために過度の利点を持つため、単一の責任パターンに違反する可能性が最も高いためです。

変更不可能なデータクラスの場合：

このような場合には、私はリッチドメインモデルに共有エンティティをマッピングし、その逆と思いマッパ層を有するお勧めします。あなたのコードは、主にリッチドメインモデルを扱います。このアイデアは、コードの再利用とテスト容易性に悪影響を与えるため、サービス・クラスに多大なビジネス・ロジックを課すことではありません。 もちろん、デザインはアートであり、黒と白だけではありません。データクラスは、あなたが言ったように、DTOや共有可能な変更不可能なエンティティとして不可欠です。しかし、堅牢なドメイン駆動型設計では、これらを控えめに使用し、コードベースでのフットプリントを最小限に抑えます。