1

新しいプロジェクトを開始しています。私はDDDのアプローチに従いたいと思っています。私たちはビジネスと話し、ドメインについてある程度の詳細な洞察を得ることができました (インターネット TV)。

チームは 5 人で分散しています。データアクセスにはリポジトリパターンを採用しています。私たちは全体的にサービスベースのアプローチに従っています。一部の操作は REST API を介して公開し、一部は独自のクライアント アプリケーションを介して公開します。

ORM の経験がない人 (私も現時点では大量に持っているわけではありません) は、エンティティ間の関係を持たないエンティティをモデル化したいと考えています。これは、リポジトリを使用する開発者が ORM がどのような影響を与えるかを正確に知る必要があるという理論的根拠があります。データベースに持っています。私が指摘したいのは、これは非常におしゃべりな一連のサービス、維持およびテストするコードの増加、そして根本的に要点を逃したドメイン モデルになるということです。私はこれが良いアプローチだとは思いませんし、私が話をした人もそうではありません。

このアプローチの実装に対する彼らの望みは、リポジトリ ファサードの下の Linq2SQL です。これには、2 番目のモデル、モデルとドメイン モデル間のマッピング クラス/レイヤー、および汎用リポジトリを作成することが (これまで見てきたように) 不可能であるように見えるため、リポジトリ内で多くの複製が必要です。また、継承を利用する L2S エンティティをマップすることもできません (つまり、すべてのエンティティには、作成者、作成者などのプロパティが必要です)。

1 番目の質問: 考えを変える方法について誰かアドバイスをもらえますか? 私は、NHibernate を使用するサイド プロジェクトを作成中です。これはもちろん DDD アプローチをサポートしていますが、これは「コードを見せてください」が強力な議論であることに基づいています。

2 番目の質問: NHibernate を使用した on-my-own-time サイド プロジェクトで、どのようなことをデモンストレーションする必要がありますか? 私はそれに慣れていません。彼らが NHibernate を嫌う理由の 1 つは、学習曲線と XML の要件です。私の反論は、これは強力なツールであり、Fluent NHibernate は XML の必要性を排除するというものです。彼らはまだそれが好きではありません。

4

4 に答える 4

3

DDD の集約ルートの概念を見たことがありますか? 基本的に、リポジトリから集約ルートのみをリクエストすると、集約全体がロードされます。アグリゲートには、必要な操作を実行するために必要なものがすべて含まれているため、おしゃべりの懸念が解消され、ロードされているものを明確にするというチームの懸念にも対処できます。

サイド プロジェクトで、集約全体をロードする集約ルートに基づくリポジトリを示します。これはかなり単純なコードであり、その意図は非常に明確です。残念ながら、NHibernate の学習曲線に乗らなければなりませんが、このアプローチを使用すると、「魔法」が少なくなります。

于 2008-10-21T22:49:40.273 に答える
1

あなたの説明から、あなたが構築している各サービスは特定のエンティティを中心としており、ドメインモデルが異なるエンティティを必要とする場合、異なるサービスを使用する必要があると推測しています。

この場合、サービスの粒度が細かすぎることをお勧めします。これらのサービスの実装の一部であるドメイン モデルを使用して、実行する必要があるプロセスの周りにサービスのインターフェイスを構築することをお勧めします。SOA がシステムを一連のサービスとして公開することを提唱していることは理解していますが、単一システムのコンポーネントの内部相互作用はサービスであってはなりません。

このアプローチは、単一のエンティティとの基本的な相互作用ではなく、粗粒度の動作を公開するこの上にサービスを配置して、エンティティを関連付ける手段およびリポジトリの基礎として集約ルートを使用するリッチ ドメイン モデルにつながります。システムの内部にあるクライアント アプリケーションは、これを提供できます (同じドメイン モデルを使用)。

モデル内のエンティティが関連しており、これらの関係がシステムの動作にとって重要である場合、これらの関係を強制する必要があります (システムがモデル化されているドメインを反映するようにするため)。各エンティティが独立している場合、特にそれらはサービスです。

すべてのエンティティ サービスが相互に呼び出す必要があるシステムになってしまうか (多くの結合が作成され、変更管理のオーバーヘッドが増加するなど)、関係を強制できなくなります。つまり、モデルが希薄化され、潜在的に結果的に一貫性のない動作または欠落しているデータ。

これは基本的に、相反する力である高結合力と低結合力の基本原則に帰着します。ソリューションでそれらのバランスを取る必要があります。関係 (または暗黙的な関係) がない場合、結束を犠牲にして結合が低くなり、表されていない関係が実際に存在するか、より高いレベルで依存関係が増加している場合、メンテナンスの問題が発生する可能性があります。あまりにも多くの関係を強く強制すると、ドメイン モデルが泥の玉になり、管理不能になることになります。これに関する具体的なアドバイスは難しいですが、一般的には、集約を使用してモデルを構築することから始め、集約内部の関係に集中し、モデルを頻繁に確認します。

特に NHibernate では、それが提供するクリーンな抽象化、必要なコードの削減、コードを変更せずに簡単に構成できること、提供される機能の量 (ID マップや作業単位など) を実証することをお勧めします。

于 2008-10-21T23:29:43.810 に答える
1

休止状態を使用していないため、詳細を説明できません。しかし、このようなほとんどすべてに当てはまる一般的な真実は次のとおりです。

「すべてを可能な限りシンプルにしますが、シンプルにしないでください。」
   -  アルバート・アインシュタイン

したがって、私の意見では、システムを適切に定義しておくために、可能な限り最小限の接続を使用することになります。そして、すべてを接続しようとするのは避けてください。後ろから噛まれるからです (プログラミングにおける疎結合の原則を思い出してください)。

于 2008-10-15T09:08:32.650 に答える
0

あなたのチームは、コードをもう少し良くするために、データベースを具体的なクラスのセットにマッピングする方法として ORM を使用しているようです。抽象化されたデータベース モデルだけでなく、代わりにドメイン モデルを作成することを考えている場合は、リレーションシップを含める必要があることは明らかです。舞台裏でデータがどのようにロードされるかは別の問題です。

于 2008-10-21T23:13:21.520 に答える