6

私は現在、ORM を使用して既存のアプリケーションを再モデル化している最中か、再モデル化を試みており、可能な限り DDD に準拠しようとしています。

作業指示書は AR であり、12 を超える子エンティティがあります。私はこのクラスを次のようにモデル化するつもりでした:

class WorkOrder {

  private $number = 0;
  private $manual = '';

  ...

  // Sub-Entities

  private $consumables; // Collection (1:m)
  private $dimensions;  // Collection (1:m)
  private $sequences;   // Collection (1:m)

  ...

}

ここで、この集約ルートをロード (および永続化) するためのリポジトリが必要になります -- 正しいですか?

レポは 1 つ以上の集計を返し、サブエンティティにアクセスすると (ドット表記ではなく間接的なゲッター/セッターを介して)、求めている情報を遅延ロードしますか???

作業指示書を作成するためのファクトリとして機能する別のクラスを用意します。これは詳細なプロセスであり、実質的なビジネス ロジック/検証ルールが含まれています...

しかし、工場が作業指示書の集約を作成した場合、レポは AR を永続化するだけでしょうか?

このファクトリは、(REST またはその他の方法で) サード パーティ サービスにクエリを実行し、基本的に作業範囲を説明する承認済みドキュメントのスナップショットを作成する必要があります。

では、リポジトリは ORM をカプセル化するのでしょうか、それともどの永続レイヤーを選択すればよいのでしょうか?

現在、私のファイル構造は次のようになります。

WorkOrder/
  /Factory.php
  /Aggregate.php
  /Repository.php

  /Entity/Header.php
  /Entity/Shipping.php
  /Entity/Warranty.php
  /Entity/Certification.php
  ...

リポジトリには次のようなメソッドがあります。

FindOneByTrackingNumber()
FindAllByCriteria()

save($root);

私の工場には次のようなメソッドがあります。

createWorkOrderFromRpi()
createWorkOrderFromCsv()
...

ここでいくつかの記事と数え切れないほどの投稿を読みました。

http://williamdurand.fr/2013/08/07/ddd-with-symfony2-folder-structure-and-code-first/

詳細は素晴らしいですが、私自身の解釈についてセカンドオピニオンが必要です. :)

よろしく、アレックス

4

1 に答える 1

14

Doctrine は DDD に適合しません。ドメイン オブジェクトの深い関係を処理できません。多くの注釈を書いたり、メタデータをマッピングしたりせずに、実際にオブジェクトを非常にうまくマッピングする ORM は他にないと思います。ドメイン モデルを正しく構築する場合、ORM は役に立ちません。

DDD の基本ルールの 1 つを考慮する必要があります。つまり、集約ごとに 1 つのトランザクションです。そのルールを念頭に置いてドメイン モデルを設計すると、持続性にも役立ちます。リレーショナル データベースが不要になったことに気付くことさえあります。RDBMS を使用しても、スケーラビリティに役立ちます。

はい、ケースの 99% でリポジトリがドメイン オブジェクトの永続化に使用されます。リポジトリは、ドメイン オブジェクトが気にする必要のないメソッドであるデータのリフレクションを使用してドメイン オブジェクトを自動的に設定する ORM ではなく、マッピングを処理する必要があります。

リポジトリで独自のマッピングを作成する (単純なプロパティ データベース テーブル列のマッピング) ことは、集計の削除と保存に関しては難しくありません。問題は集約の更新にありますが、問題はマッピングではなく、ドメイン オブジェクトの状態変化の追跡にあります。しかし、これはマッピングの問題ではなく、作業単位の問題です。

ここで、この集約ルートをロード (および永続化) するためのリポジトリが必要になります -- 正しいですか?
正しい。リポジトリは、ドメインの状態の変更を保持し、ドメインの状態を再構成します。

レポは 1 つ以上の集計を返し、サブエンティティにアクセスすると (ドット表記ではなく間接的なゲッター/セッターを介して)、求めている情報を遅延ロードしますか???
はい、ゲッターを使用できます (ドメイン モデルを使用して UI を設定する場合は、ドメイン モデルを使用してドメインの状態を追跡するためだけに cqrs を使用します)。セッターを持つべきではなく、状態を変更するメソッドだけを持つべきです。これらのメソッドはユビキタス言語 (changeName、addItemToCart) を反映しています。遅延読み込みは、メモリを節約するためだけに役立ちます。メモリに問題がない場合は、ドメイン オブジェクトのスナップショットを最新の状態にすることもできます。はい、遅延読み込みはORMの仕事であり、ドメインオブジェクトにある種のゲッターを持たせることを強制します.これはDDDの大きな制限です.

しかし、工場が作業指示書の集約を作成した場合、レポは AR を永続化するだけでしょうか?
ファクトリは、ドメインに新しい状態を作成します。リポジトリは、工場によって一度作成された状態を再構成します。

では、リポジトリは ORM をカプセル化するのでしょうか、それともどの永続レイヤーを選択すればよいのでしょうか?
はい、リポジトリはドメイン状態の再構成を処理する必要があります。ORM は単なる技術的な問題であり、単なるライブラリです。とにかく、ORM は共通ライブラリ/共有カーネル レイヤーの一部であり、リポジトリはインフラストラクチャ レイヤーの一部です。

ファイル構造に関しては、DIP、IOC、DDD 境界コンテキストについて詳しく読む必要があります。これは、コンポーネントに基づいてアプリケーションを構築するのに役立ち、コンポーネントをスケーラブルなアプリケーションに分離します。

于 2014-06-22T08:50:23.847 に答える