2

私はWebアプリケーションの基本アーキテクチャを設計しているところです。ビジネスモデルとロジックが非常に複雑であるため、プロジェクトはドメイン駆動設計アプローチに従います。

このプロジェクトは、 SOAプロジェクト（サービス指向アーキテクチャー）を目指しています。だから私はサービスとそれを中心にプロジェクトを構築する方法について多くを学んでいます。

私の前の質問に続いて、モデルクラスの関連付けに関する質問があります。

モデルクラスは永続性に関連することを知り、何もするべきではないことを理解しています。ただし、モデルクラス間の関連付けがある状況を判断するのに問題があります。

例えば：

  • クラスPerson
  • クラスCarには1つのドライバーがあります（例）

getDriverとはどこにあるべきgetCarsですか？

  1. モデルクラス：$car->getDriver()
  2. プリミティブ型のサービスレイヤー：$personService->getPerson($car->getDriverId())
  3. OOPを使用したサービスレイヤーで：$carService->getDriver($car)

解決策1.より自然なようです。Doctrine 2を使用しているので、モデルの関連付けはDBマッピングアノテーションで処理されます。そうすれば、モデルは永続性に関連することは何もしません（実際にはDoctrineを介して行いますが）。それは私のお気に入りの解決策ですが、最初に「車」のリストをロードすることを除いて、サービスのポイントは何ですか？

解決策2.OOPを破棄し、モデル/サービスユーザーが関連付けをフェッチするためにデータベースモデルについて知っている必要があるため、愚かなようです（このIDが「個人」IDであることを知っている必要があります）。そして、彼は自分で協会をしなければなりません。

ソリューション3はソリューション2よりも少し優れていますが、それでもOOPはどこにありますか？

だから、私にとっては解決策1が最高です。しかし、私はソリューション2とソリューション3が実際のプロジェクトで使用されているのを見たことがあります（時には一緒に混合されることもあります）ので、疑問があります。

また、次のような追加のパラメータがある場合、質問はより複雑になります。

$person->getCars($nameFilter, $maxNumberOfResults, $offset);

（この場合、実際にはSQLクエリ/永続クエリのように見えます）

では、ドメイン駆動設計アプローチに従ったプロジェクトのモデル/サービスアーキテクチャに使用する必要があるのはどれですか？SOAの場合、モデルはロジックのない「ダム」データコンテナのみにする必要がありますか？もしそうなら、DDDアプローチはどこにありますか？

4

4 に答える 4

1

プロジェクトがDDDの場合、モデル/サービスアーキテクチャが必要な理由がわかりません。IMOこれは貧血モデルを作成し、すべてがほとんど手続き型です。

さて、DDDであるということは、データベースを気にしないことを意味します。ただし、（少なくとも論理的には）2つのモデルがあります。ドメインと永続性です。ドメインモデルは、ビジネスケースを表すのに最も適した、最も自然な方法で関連付けを処理します。「1つのドライバーを持っている」または多くを持っているのは、DDDには存在しないdb中心の考え方です。永続性モデルは、集約ルートがデータベースに格納される方法を処理します（ここで、ORMエンティティとその関係などを定義します）。

あなたの質問については、まず第一に、文脈と目的が重要です。厳密にクエリ（ユーザーに表示するため）の場合は、単純なモデルを使用でき、DDDやビジネスルールは必要ありません。コントローラは、DTOとして返されるデータを専用のクエリリポジトリに直接要求できます。

人や車を更新したい場合は、アプリケーション層で（私は通常コマンドベースのアプローチを使用しているので、私の場合、これらはすべてコマンドハンドラーで行われますが、アーキテクチャ的にはアプリケーション層の一部です）、次のことができます。タスクに最適なARを（ドメイン）リポジトリから取得します。ドメインリポジトリは、単純なDTOを返すクエリリポジトリとは対照的に、getPerson（$ id）がドメインエンティティを返す必要があることを認識しています。

$person=$repo->getPerson($id);
//do stuff
 $repo->save($person);
 //optionally raise event (if you're using the domain events apprach)

ただし、注意が必要なのは、どのコンテキストでARが何であるかを判断することです。車にはどのような状況で1人のドライバーがいますか？ドライバーは本当に車に属していますか？オーナーのコンセプトはありますか？あなたはPersonクラスを持っていますが、人は運転手または所有者になることができます（またはそれがレンタル会社の場合はそうではありません）。ご覧のとおり、これはドメインに大きく依存します。ドメインの明確なイメージが得られて初めて、データをどのように保存し、リポジトリからどのオブジェクト（エンティティ）が返されるかを考えることができます。

于 2012-06-29T06:58:27.123 に答える
1

DDD のコンテキストでは、これは、エンティティ間の関係が直接的なオブジェクトの関連付けとリポジトリのどちらを介して表現されるかを決定する問題です。どちらのアプローチも有効であり、関係の性質によって異なります。たとえば、ドメイン内で、ある人物に多数の車が関連付けられている可能性があり、その人物エンティティから一連の車に直接関連付けられても意味がありません。エンティティ、具体的には集約ルートの役割は、不変条件を保護し、ビジネス ルールを適用することです。人物に関連付けられた車のセットが、人物クラスに存在するどの動作にも必要ない場合、関連付けを人物エンティティに配置する理由はありません。さらに、例が示すように、車のクエリをフィルタリングする必要がある場合があります。あなたの質問に答えるために、リポジトリ。SOA は DDD と直交しており、ビジネス機能へのアクセス方法とデプロイ方法に重点を置いています。オニオン アーキテクチャとも呼ばれる六角形アーキテクチャの観点から、DDD と SOA の相互作用を検討することは有益です。ドメインはコアにあり、ドメインの周りに API ファサードを形成する一連のアプリケーション サービスによってカプセル化されています。これらは、ヘキサゴナル/オニオン アーキテクチャのポート/アダプタである SOA のサービスとは異なり、これらのアプリケーション サービスを SOA サービスとして公開します。

于 2012-06-29T00:22:06.133 に答える