問題タブ [domain-driven-design]

ERP システムとやり取りするカスタム アプリの作成に主に取り組んでいる中規模企業で仕事を始めています。この種の仕事をするのは初めてなので、ERP の概念は私にとって初めてで、少しずつ学んでいます。

私はこれまでに 2 つのアプリしか作成しておらず、データベース モデルを学びながら、仕事を成し遂げるのに必要な分だけしか学んでいませんでしたが、その限られた量でも、全体像が形成されるのを見始めることができます。私の考えは、新しいアプリケーションがこのライブラリを参照できるように、すべてのマッピング/モデル オブジェクトが格納されたライブラリを作成することでした。その後、各アプリケーションは独自のリポジトリを作成し、必要なものと意味のあるパースペクティブのみへのアクセスを制限します。

私が抱えている問題/質問は、(N) Hibernate マッピング内の関係を処理する方法です。この基本ライブラリに完全な関係がマップされた注文オブジェクトがある場合、誰かがそれらの関係を永遠に移動するのを止めるものは何もありません (私が唯一のプログラマーであることを認めます...)。したがって、リポジトリを一種のスコープの限定として使用することは、この意味ではまったく機能しません。

代わりに、この注文オブジェクトの (N) Hibernate マッピングで関係を制限すると、リポジトリは、スコープに必要な関係のみにバインドされた注文オブジェクトを返します。欠点は、単一の「マッピング ストア」ではなく、プロジェクトごとにマッピングを作成する必要があることです。

他の人はこれにどのように対処しますか？

無関係ですが、(N)Hibernate の永続オブジェクトを変換して、いくつかの関係で構成されている可能性があり、特定のアプリケーションにより適した一種の単一の非永続オブジェクトに変換しています (通常は、UI の影響を大きく受けます)。これは一般的なことですか、それとも、返されたオブジェクトを取得して別のものに変換することで、(N) Hibernate の利点の一部を捨てているのでしょうか?

ps。DDDタグについて... これがDDDが詳細に対処するものかどうかはわかりませんが、本を注文しています. ただし、本が到着する前に見る良いリソースがわかりません。

私は2つの崩壊問題を見つけました:

• ドメイン エキスパートと開発チーム (DDD) の間で同じ言語を使用する必要があります。
• コード内の命名には英語を使用する必要があります (.Net 設計ガイドライン)。

ドメインの専門家が英語を話せない場合はどうなりますか?

ドメイン駆動設計では、豊富なドメイン モデルを使用することが推奨されます。これは、すべてのドメイン ロジックがドメイン モデルにあり、ドメイン モデルが最高であることを意味します。ドメインモデル自体は理想的には永続性について何も知らないため（データベースなど）、永続性は外部の問題になります。

私は中規模のワンマン プロジェクト (Java の 10 万行以上) で実際にこれを使用してきましたが、多くの利点を発見しています。主に、データベース指向のアプローチに対してこれが提供する柔軟性とリファクタリング性です。ドメイン クラスを追加および削除し、いくつかのボタンを押すだけで、まったく新しいデータベース スキーマと SQL レイヤーが展開されます。

しかし、豊富なドメイン ロジックと、アプリケーションを支える SQL データベースがあるという事実とを調和させるのが難しいという問題に直面することがよくあります。一般に、これは典型的な「1+N クエリの問題」を引き起こします。つまり、N 個のオブジェクトをフェッチし、各オブジェクトに対して重要なメソッドを実行して、クエリを再度トリガーします。これを手動で最適化すると、一定数の SQL クエリでプロセスを実行できます。

私の設計では、システムがこれらの最適化されたバージョンをプラグインできるようにしています。コードを、数十のドメイン固有のクエリ (getActiveUsers など) を含む「クエリ モジュール」に移動することでこれを行います。ナイーブでスケーラブルではない) および SQL ベースの (展開で使用する) 実装。これにより、ホットスポットを最適化できますが、主な欠点が 2 つあります。

• ドメイン ロジックの一部を実際には属さない場所に効果的に移動し、実際には SQL ステートメントにプッシュすることさえあります。
• このプロセスでは、クエリ ログを精査してホットスポットの場所を特定する必要があります。その後、コードをリファクタリングし、コードをクエリに落としてレベルの抽象化を減らす必要があります。

ドメイン駆動設計とそのリッチ ドメイン モデルを、すべてのエンティティをメモリ内に保持することができず、データベース バックエンドに限定されるという事実と調和させる、より適切でクリーンな方法はありますか?

私が現在取り組んでいるプロジェクトには、多くの検索/フィルタリングページが必要です。たとえば、データ、カテゴリ、ユニットなどで問題を取得するための複雑な検索ページがあります。

問題ドメインクラスは複雑で、多くの値オブジェクトと子オブジェクトが含まれています。

。UIの検索/フィルタリング/レポートをどのように処理するのか疑問に思っています。私の知る限り、私には3つの選択肢がありますが、どれも私を幸せにするものではありません。

1.）パラメータをRepository / DAOに送信して、DataTableを取得し、DataTableをUIコントロールにバインドします。たとえば、ASP.NETGridViewに送信します。

このオプションでは、ドメインレイヤーを渡すだけで、指定された仕様のデータベースをクエリできます。そして、完全に構築された複雑なドメインオブジェクトを取得する必要はありません。値オブジェクト、子オブジェクトなどは必要ありません。データベースから直接DataTableのUIに表示するデータを取得し、UIに表示します。

しかし、メソッドの戻り値のようにUIで計算フィールドを表示する必要がある場合は、完全なドメインオブジェクトがないため、データベースでこれを行う必要があります。インテリセンスなどのロジックとDataTableの問題を複製する必要があります...

2.）パラメータをリポジトリ/ DAOに送信してDTOを取得し、DTOをUIコントロールにバインドします。

このオプションは上記と同じですが、検索ページごとに貧血のDTOオブジェクトを作成する必要があります。また、さまざまな問題検索ページについて、問題オブジェクトのさまざまな部分を表示する必要があります。IssueSearchDTO、CompanyIssueTO、MyIssueDTO...。

3.）パラメータをReal Repositoryクラスに送信して、完全に構築されたドメインオブジェクトを取得します。

私はドメイン駆動設計とパターンが好きです。このオプションにはDTOまたは複製ロジックはありませんが、このオプションでは、UIに表示されない多数の子オブジェクトと値オブジェクトを作成する必要があります。また、完全なドメインオブジェクトと針の子のパフォーマンスコストを取得するには、ロットのob結合が必要です。オブジェクトと値オブジェクト。

私はORMツールを使用していません。このバージョンでは手動で遅延読み込みを実装できるかもしれませんが、少しやり過ぎのようです。

どちらが好きですか？それとも私は間違っていますか？これを行うための提案やより良い方法はありますか？

Composite UI Application Block (CAB)/Smart Client Software Factory (SCSF) を使用して構築された複合アプリケーションがあります。これまで、複合アプリの各モジュールは独自の DTO セットを使用しており、ビジネス ロジックは UI レイヤーとサービス レイヤーの両方でモジュール全体に複製されています。UI層とサービス層、そして（理想的には）モジュール全体に分散できるドメイン層にビジネスロジックをカプセル化するために、よりドメイン駆動型のアプローチを追求したいと考えています。

開発中の複合アプリケーションには一度に複数のモジュールがあり、それらを任意の順序でデプロイできる必要があります。理想的には、私たちのモジュールが共通のドメイン モデルを共有することを望んでいますが、ドメイン モデルの新しいバージョンをモジュールと共にデプロイする場合、ドメイン モデルに対して他のモジュールを回帰テストする必要があるのではないかと心配しています。 .

別の方法は、各モジュールでドメイン モデルを複製することのようですが、そのコードの複製すべてが私にはおかしいにおいがします。業界は、この種の状況に対するベスト プラクティスを開発しましたか?

顧客のドメイン エキスパートと協力しているとします。あなたは、彼らの問題のあなたのモデルが彼らのものよりも明確であることを認識しています (または少なくとも合理的な信念を持っています)。彼らがあなたの道を行くべきだとどのように彼らを説得しますか.

私の場合、要件の主な目的が何であるかはかなり明確です (たとえば、製品の取引システム)。私の経験と調査に基づいて、2 つの TraderParties を持つ TradeContract をお勧めします。各 TraderParty は、1 つの Product を購入し、1 つの Product を販売します。コンポジットを XML でモデル化する必要がある場合、次のようにモデル化できます。

上記は単に、アンがボブからハリー・ポッターとアズカバンの囚人を 20.00 ドルで購入したモデルです。より抽象的に言えば、これは二者四足の取引をモデル化したものです。tradeContract議論のために、XML を使用するシステムが XML を検証し、取引を調整すると仮定しましょう。

ドメインの専門家がこれが複雑すぎると感じたらどうしますか? 上記のドメイン モデルに到達するためのいくつかの中間ステップを容易に認めることができますが、「弾丸をかじって」上記のドメイン モデルを遅かれ早かれ使用する方がよいと彼らを説得するにはどうすればよいでしょうか?

追加: SME が提案するモデル ...

ドメインの専門家が話し続けているのは、私が思いついたモデルですが、彼らのビジネス プロセスはまだその準備ができているとは考えていないようです。（それでも、今はやり遂げる方法があると思います）。

彼らがすぐに欲しいモデルは次のとおりです。

このモデルは、アンが 20.00 ドルを寄付したものです。次に、別のトランザクションを入力する必要があります。

彼女がハリー・ポッターの本を手に入れたというモデルに。私たちのシステムがアンをだますかどうかをモデル化できないため、私の意見ではかなり面倒です。同様に、同様の種類のトランザクションの断片化が、貿易契約のボブ側で発生します。

Linq2Sql がとても好きなので、Linq to Sql をデータレイヤーとして使用して単純な Web アプリを作成しています。私は最近、DDD と TDD について少し読んでいて、試してみたいと思っていました。

何よりもまず、Linq2Sql と DDD がうまく機能していないことに気が付きました。私のもう 1 つの問題は、テストを見つけることです。実際、良いテストを定義するのは非常に難しいと感じているので、質問したいと思いました。

ドメイン駆動設計では、ファクトリを使用してドメイン レイヤーにドメイン オブジェクトを作成することをお勧めします (直接コンストラクターまたは IoC を使用するのではなく)。

しかし、プレゼンター レイヤーでドメイン オブジェクト ファクトリを使用する場合はどうでしょうか。たとえば、プレゼンターから取得したユーザー入力からドメイン オブジェクトを作成していたとします。

以下に例を示します。10 進数の設定を持つ構成ドメイン オブジェクトがあるとします。

パブリック クラスの構成: PersistantObject {

}

このオブジェクトをプレゼンター レイヤーではなくドメイン レイヤーで作成するには、これらの各 10 進数値を関数パラメーターとして渡す必要があります。扱いにくい関数定義と呼び出しを作成します。

つまり、ConfigurationService.CreateConfiguration(温度、...(x20)、重力);

おそらくより良い解決策は、構成オブジェクトをプレゼンター レイヤーに作成し、構成オブジェクトのすべての値をユーザー入力から直接割り当てて、長い関数呼び出しをスキップすることです。

構成 config = ConfigurationFactory.CreateNewConfiguration();

config.temperature = 温度;

..(x20).. = ...;

config.gravity = 重力;

ConfigurationService.SaveNewConfiguration(config);

しかし、このアプローチが間違っているかどうか疑問に思っています。なぜですか? これらのアプローチの両方が間違っている場合、ユーザー入力から長いオブジェクトを作成するための最良のアプローチは何ですか?またその理由は何ですか?

ありがとう！

デフォルトでドメイン オブジェクト ファクトリにインターフェイスを使用することは理にかなっていますか? それとも、必要な場合にのみインターフェイスをファクトリ クラス用に予約する必要がありますか?

貧血のないドメイン モデルを目指すドメイン駆動設計では、ドメイン オブジェクトとサービス指向メソッドのどちらに実装するかをどのように決定しますか?

編集：私は例を使ってこれを別の方法で尋ねましたが、ここでより良い答えを得ました