1

アプリケーション開発者にとって、基になるデータ ストア (引数のための SQL データベース) に永続化できるドメイン オブジェクトを使用してアプリケーションを作成するための従来のパラダイムは、ドメイン オブジェクトを作成してから、テーブル構造を作成 (または生成) することだと思います。ドメイン オブジェクトの外観と、基になるデータ ストアの構造との間には密接な関係があります。したがって、ドメイン オブジェクトに情報を追加する場合は、コードにフィールドを追加してから、適切なデータベース テーブルに列を追加します。すべておなじみですか？

これは、明確に定義された構造を持つデータ ストア (テーブルと列が事前に定義および固定されている SQL データベースについて主に話している) には十分ですが、現在、ユビキタスな SQL データベースに代わる多くの代替手段が存在し、これらは多くの場合、このようにデータを制約しません。たとえば、MongoDB はNoSQLデータベースであり、データをコレクションに分割しますが、それ以外にデータの構造化はありません。新しいフィールドを追加する場合は、新しい列を定義しません。

ここで質問があります。MongoDB のようなデータ ストアの柔軟性を考えると、このデータを表すドメイン オブジェクトで同様の種類の柔軟性を実現するにはどうすればよいでしょうか? たとえば、Spring を使用して独自のドメイン オブジェクトを作成している場合、データに「middleName」フィールドを追加するときに、ドメイン オブジェクトに「middleName」フィールドを追加する必要がないようにするにはどうすればよいでしょうか? データを動的に検査し、毎回コードを変更することなくドメインオブジェクトでアクセスできるメカニズム/アプローチ/フレームワークを探しています。すべてのアイデアを歓迎します。

4

3 に答える 3

2

いくつかの選択肢があると思います：

  1. ドメインオブジェクトを持たずに動的プログラミング言語を使用できます（たとえば、clojure）

  2. Java の使用に固執している場合、mongo Java ドライバーは基本的に Map である DBObject でデータを返します。したがって、デフォルトの動作はすでに必要なものを提供しています。morphia (または spring-data) などのライブラリを使用して DBObject をドメイン オブジェクトにマップする場合にのみ、ドメイン オブジェクトについてまったく心配する必要があります。

しかし、Java を使用していた場合は、モルフィアを介してマップされたドメイン オブジェクトの標準的な慣例に固執します。なぜなら、フィールドを追加することは、利点と比較すると非常に小さな不便だと思うからです。

于 2012-08-17T14:59:16.687 に答える
1

質問は本質的に逆説的だと思います。
一方で、ドメインオブジェクト、つまり問題のあるドメインのデータ（および動作）を表すオブジェクトが必要です。
一方、ドメインオブジェクトがデータの変更によって明示的に影響を受けないようにする必要があると言います。
しかし、問題のドメインを表すオブジェクトがある場合は、問題のドメインを表すためにそれを実行する必要があります。
たとえば、ミドルネームが追加された場合、実際の「ユーザー」エンティティの表現を変更して、この変更を実際のユーザーに対応させる必要があります。おそらく、このデータをオブジェクトに追加するだけでなく、関連する動作（ミドルネームの検証、またはそれに関連する機能）も追加します。

本質的に、私がここで言おうとしているのは、（クラシックOO）ドメインオブジェクトがある場合、データとともに動作/機能を変更する必要があるかもしれないということです。自動で変更する方法がないためです。動作、データを自動的に変更するという問題は無関係になります。

データに関連付けられた動作を望まない場合は、基本的にDTOがあり、@Kevinの答えがあなたが探しているものです。

于 2012-08-18T03:02:33.060 に答える
1

正直なところ、あなたが説明したように、データに応じてフィールドが「任意に」追加または削除される、ある種のブラックボックス DTO を探しているように思えます。Mapこれにより、仕事をするのが簡単なことを提案する傾向があります。ドメイン モデルが絶えず変化している場合、実際にはドメイン駆動型の設計を行うことはできません。

于 2012-08-18T03:08:19.150 に答える