0

大学の SE のクラスでは、OOAD と DDD (Java を使用) を教えられ、プロジェクトで使用するように勧められました。残念ながら、エンティティの可変性によって引き起こされる多くの課題については議論されていません。

  • マルチスレッド アプリケーションには不向き
  • equals()、hashCode()、またはcompareTo()に依存するデータ構造を破壊すること (*)
  • エンティティの状態について推論するのが難しくなる

これらの問題により、私は DDD を使用するのが非常に難しくなりますが、DDD の背後にあるアイデアは好きであり、多くのライブラリとフレームワーク (ORM、シリアライゼーション ライブラリなど、基本的に Java Beans を使用するすべてのもの) はエンティティの可変性に依存しています。その結果、私はアーキテクチャに関する決定を行う際に疑いでいっぱいになり、何をしても結果に満足することができません。エンティティが不変であるが、それを機能させるための多くの可変接着剤 (ビルダー、可変 DAO/DTO) を持っているフランケンシュタインのモンスター アプリを取得するか、WTF でいっぱいの完全に可変アプリ (毎回リストを並べ替えるなど) を持っています。エンティティがリストに追加されてから変更された可能性があるため、並べ替えられたデータ構造を使用する代わりに使用します)。

これらの問題にどのように対処しますか？行く方法は何ですか？可変性を必要としない DDD の代替手段はありますか?

私は個人的には完全に不変にすることを好みますが、そうすると Java Beans を必要とする一部のライブラリを使用することが非常に難しくなり、不可能になることさえあります。もちろん、関数型プログラミングに切り替えることもできますが、それが DDD が使用される典型的なプロジェクトの適切な代替になるかどうかはわかりません。

(*) まあ、それらをオーバーライドする場合のみ。しかし、セットを使用しない場合、セットを使用する意味はどこにありますか?

4

2 に答える 2

2

「不変のエンティティ」が何を意味するのかはわかりませんが、私には矛盾しているように聞こえます。エンティティはアイデンティティに関するものです。エンティティが作成、変更、永続化、再水和されるとき、それらを識別し、生涯にわたって追跡できるはずです...決して変更されないものを追跡して永続化することはできますが、私は失敗します関心を参照してください - アイデンティティが存在する基本的な理由は、変化するものに固定のラベルを付けるためです.

ただし、一部のドメイン オブジェクトは実際には不変性に適していますが、エンティティではなく、値オブジェクト、ID が重要でないオブジェクトです。値オブジェクトのインスタンスを別のものに簡単に置き換えることができます。結果は同じです。

あなたがしようとしているのが、すべてのドメイン オブジェクトを不変の値オブジェクトにすることである場合、これはもはや DDD ではありません。DDD は、純粋な関数型プログラミングではなく、オブジェクト指向に関するものです :)

于 2012-05-30T15:37:46.027 に答える
0

これらは一般的な問題です。次のシナリオを検討していると仮定します。

  • 永続データから「注文」オブジェクトを構築する
  • 「注文」にいくつかの変更を加える
  • 行われた変更を保持します。

同じシナリオを通過する 2 つの同時要求がある場合、次のようになります。

  • マルチスレッド アプリケーションには不向き: 1 つ目は、2 つの異なるインスタンスがあること、2 つ目は、データを保存するときに楽観的/受動的ロックを使用することです。
  • equals()、hashCode()、またはcompareTo()に依存するデータ構造を破壊すること- 2つのドメインエンティティは、それらの識別子が等しい場合に等しいです(そうでない場合、定義により不変の値型があります)。
  • エンティティの状態について推論するのが難しくなります-なぜこれが必要なのかわかりません。O/RM は、データ更新のために、DDD がストレージを認識しないことを自動的に追跡します。変更の追跡がビジネス ロジックの一部である場合、それを実装する必要があります。
于 2012-05-31T11:10:24.373 に答える