DDD（java）集約ルーツと永続性

Question

私は様々なサイズのテーブルを使用するアプリケーションを作成していますが、DDDというラベルのプロジェクトでは永続性の部分を正しく取得できないため、私は物事を研究していました。私が完全に把握していない一つのことは、具体的な例を見つけることができないように見えます。私はORMを使わずに作業しています。（これは実際にはdb固有のプロジェクトであるため、ORMを使用することはできません。私は簡単にはできないでしょう）。私はstackoverflowの具体的な例を見回しましたが、実際には私の特定の問題を説明するものはありません。

私はあなたが私は明らかに任意の列を破棄し、テーブルのエンティティを取得するたびに、すでにに追加した場合、またはコレクションから削除列コレクションを設定見ての通り、以下のコードは

public DataTable getTableByID(int id) throws AccessException{ 
    DataTable result = this.context.TableContext().getEntityByID(id); 
    result.setColumns(getColumnsByTableID(id));  
    return result; 
} 

private List<DataColumn> getColumnsByTableID(int id){ 
    Object[] arguments = { id }; 
    return this.context.ColumnContext().getUnitsWhere("TABLE_ID = ?", arguments); 
} 

権利であることを疑いますテーブルはすでに記憶されていました。私はどこでどのように私は列を取得する必要があります（私はテーブルクラス内のリポジトリを呼び出すと考えてきたが、それについては何か感じていない）。永続性については、オブジェクトのリストをオブジェクトに追加するときに、オブジェクトを簡単に取得することもできますが、オブジェクトを削除すると検出方法がないこれをキャッチするためのイベントを入れることは、不正行為になります:)）。正しい方向に少し押していただければ幸いです。ありがとうございます。

Answer 1

DDDは、テクノロジーに依存しない一連のガイドラインです。しかし、ドメインオブジェクトが長期間存続する（すなわち、プロセスの再開に耐えられる）プロジェクトでは、永続性問題、リレーショナルデータベースを使用する場合のORMなどのインフラストラクチャが必要です。そのような場合、ORMは必要不可欠なので、ドメインモデルは永続性に不可欠なものにする必要があります。あなたは、あなたのドメインモデルで永続的な問題が「流出」しないようにします。今問題は、既存のORMを使用するのか、独自のORMを構築するのかです。そして、あなたがそれを実現するかどうかにかかわらず、あなた自身のものを造ろうとしているように見えます。 ORMを構築することは、大きな事業であり、独自のプロジェクトです。私は、ORMとアプリケーション自体を合理的な時間内に構築することが、どれほど現実的であるかを確かめることはできません。

オブジェクト・リレーショナル・行動パターン：作業の単位（184）、アイデンティティ マップ（195）、レイジーロード（200）いずれにせよ、Martin Fowler氏は、あなたが見たいかもしれませんpatternsのセットを持っています

オブジェクト・リレーショナル構造パターン：アイデンティティフィールド（216）、外国 キーマッピング（236）、アソシエーションテーブルマッピング（248）、依存マッピング （262）、エンベディッド・バリュー（268）、直列化されたLOB（272）、単一テーブル 継承（278）、クラステーブル継承（285）、具体的なテーブル 継承（293）、継承マッパー（302）。

オブジェクトリレーショナルメタデータマッピングパターン：メタデータマッピング（306）、 クエリオブジェクト（316）、リポジトリ（322）。

具体的な問題についてはIdentity MapとData Mapperをご覧ください。実装のヒントについては、Hibernateのソースを見ることもできますが、圧倒的なこともあります。