1

SQL Server 2008 R2 バックエンドで C# 3.0 と ASP.NET 3.5 を使用して単純なプロジェクト管理システムを作成しています。

現時点では基本的に、基本的な CRUD 機能、少量のビジネス ロジック、およびいくつかの検証を備えたデータ ドリブン アプリケーションです。

このシステムは、より複雑なビジネス機能を含むように成長することが予想されます。私は、ドメイン駆動設計 (DDD) の原則を使用してシステムを改造することに興味があります。

現時点でのシステムの状態からすると、これはやり過ぎだと認識しており、今のところ貧血ドメインを作成することを期待しています.

システムは、顧客、クライアント、プロジェクト、コンポーネント、およびアクティビティで構成されています。

顧客には、0、1、または多数のクライアントがあります。クライアントには 0、1 または多くのプロジェクトがあります プロジェクトには 0、1 または多くのコンポーネントがあり、コンポーネントには 0、1 または多くのアクティビティがあります。

DDDを使用してこれをモデル化するにはどうすればよいですか? Customer、Client、Project、Component、および Activity を Aggregate ルートとして持つか、それとも 1 つの Aggregate ルート (Customer) を持ち、Customer を介してアクセス可能なエンティティとして Client、Project、Component、および Activity を持つか? エンティティ/集約ルート間の多対 1 の関係をモデル化する推奨される方法はありますか?

これは値オブジェクト（明らかに顧客、クライアントなどにはいくつかの属性が含まれています）などには触れていませんが、私はここで完全な初心者であり、ほぼ完全な答えと同じくらいいくつかの指針が大好きです。

質問のオープンエンドの性質についてお詫び申し上げます。私はすでに動作するシステムを持っていますが、将来を見据えています。

ありがとう、リッチ。

4

2 に答える 2

3

ドメイン駆動設計の核心はソフトウェア分析ではなく、ビジネス分析です。DDD のアイデアとパターンを適用すると、おそらく、顧客、クライアント、プロジェクト、コンポーネント、およびアクティビティとはまったく呼ばれない集合体とエンティティになるでしょう。

クラス/エンティティの特定のセットを前提として、それらに DDD ビルディング ブロックを適用しようとしても、すぐにはうまくいかない場合があります。

初心者には、Eric Evans による Domain Driven Designという本を (再) 読むことをお勧めします。また、最初の数章だけでなく、後半の部分 (パート III - より深い洞察へのリファクタリングとパート IV - 戦略的設計) は、低レベルのビルディング ブロックを扱うより戦術的なパート II よりもはるかに重要です。

更新:時間のかかる分析 (DDD は非常にコストがかかり、複雑なドメインにしか適していません) を行わずにモデリングの演習を行いたいだけの場合は、Streamlined Object Modelling: Patterns, Rules, and Implementation を読むことをお勧めします。

于 2012-09-04T11:35:18.043 に答える
0

通常、このタイプのすべての要素を集約ルートとして配置します。たとえば、タイプごとにグループ化されたアクティビティのレポートを作成するために、独立したエンティティとしてアクティビティにアクセスする必要がある場合、モデルの将来の成長や変更を見ることができませんでした活動を月ごとに分割し、サブレポートを作成してクライアントまたは顧客ごとに情報を展開します。この時点から、顧客からのレポートを作成してみてください - クライアントの活動は難しく、応答を処理して作成するためのコードを追加する必要があることを確認してくださいレポート。

顧客をルートと考えることができますが、子エンティティの親への参照を避けないでください。これは頭痛の種にならないためのベストプラクティスだと思います。

于 2012-09-04T11:45:12.787 に答える