「その他」の集合体の状態をどこで検証する必要がありますか？

シナリオ：

顧客が注文し、製品を受け取った後、注文プロセスに関するフィードバックを提供します。

次の集計ルートを想定します。

• お客様
• 注文
• フィードバック

ビジネスルールは次のとおりです。

1. 顧客は自分の注文についてのみフィードバックを提供でき、他の人のフィードバックは提供できません。

2. 顧客は、注文に対する支払いが済んでいる場合にのみフィードバックを提供できます。

   class Feedback {
       public function __construct($feedbackId,
                                   Customer $customer,
                                   Order $order,
                                   $content) {
           if ($customer->customerId() != $order->customerId()) {
               // Error
           }
           if (!$order->isPaid()) {
               // Error
           }
           $this->feedbackId = $feedbackId;
           $this->customerId = $customerId;
           $this->orderId = $orderId;
           $this->content = $content;
       }
   }
   

ここで、企業が新しいルールを望んでいると想定します。

3. 顧客Supplierは、注文の商品がまだ稼働している場合にのみフィードバックを提供できます。

   class Feedback {
       public function __construct($feedbackId,
                                   Customer $customer,
                                   Order $order,
                                   Supplier $supplier,
                                   $content) {
           if ($customer->customerId() != $order->customerId()) {
               // Error
           }
           if (!$order->isPaid()) {
               // Error
           }
           // NEW RULE HERE
           if (!$supplier->isOperating()) {
               // Error
           }
           $this->feedbackId = $feedbackId;
           $this->customerId = $customerId;
           $this->orderId = $orderId;
           $this->content = $content;
       }
   }
   

最初の2つのルールの実装をFeedback 集約自体の中に配置しました。特に、Feedback集合体が他のすべての集合体をIDで参照しているので、これを行うのは快適 です。たとえば、Feedbackコンポーネントのプロパティは、他の集約の存在を知っていることを示している ので、これらの集約の読み取り専用の状態も知っておくと安心です。

ただし、そのプロパティに基づいて、Feedbackアグリゲートはアグリゲートの存在を認識していないSupplierため、このアグリゲートの読み取り専用の状態を認識して いる必要がありますか？

ルール3を実装する別のソリューションは、このロジックを適切なに移動することCommandHandlerです。しかし、これはドメインロジックを私のオニオンベースのアーキテクチャの「中心」から遠ざけているように感じます。

トランザクションの正確さのために、別のアグリゲートの現在の状態を知っているアグリゲートが必要な場合は、モデルが間違っています。

ほとんどの場合、トランザクションの正確性は必要ありません。企業は、レイテンシと古いデータを許容する傾向があります。これは、検出と修正が容易な不整合に特に当てはまります。

したがって、コマンドは状態を変更するアグリゲートによって実行されます。必ずしも正しいとは限らないチェックを実行するには、必ずしも他のアグリゲートの状態の最新のコピーが必要ではありません。

既存の集約のコマンドの場合、通常のパターンはリポジトリを集約に渡し、集約はその状態をリポジトリに渡します。これにより、他の集約の不変の状態/予測を返すクエリが提供されます

class Feedback {
    void downvote(Repository<Supplier.State> query) {
        Supplier.State supplier = query.getById(this->supplierId);
        boolean isOperating = state.isOperating();
        ....
    }
}

しかし、構築パターンは奇妙です。オブジェクトを作成しているとき、呼び出し側は内部状態を提供しているので、内部状態をすでに知っています。同じパターンが機能し、それは無意味に見えます

class Feedback {
    __construct(SupplierId supplierId, SupplierOperatingQuery query ...) {
        Supplier.State supplier = query.getById(this->supplierId);
        boolean isOperating = state.isOperating();
        ....
    }
}

すべてのドメインロジックをドメインオブジェクトに保持することでルールを守っていますが、そうすることでビジネスの不変条件を実際に保護することはしません（アプリケーションコンポーネントが同じ情報をすべて利用できるため）。作成パターンについては、次のように記述してもよいでしょう

class Feedback {
    __construct(Supplier.State supplier, ...) {
        boolean isOperating = state.isOperating();
        ....
    }
}

これは古い質問であることは承知していますが、この問題は誤った前提に直接起因していることを指摘しておきます。つまり、存在することを想定している集計ルートは、単に正しくありません。

説明したシステムに存在する集約ルートは、Customerのみです。注文とフィードバックの両方は、それ自体が集合体である場合がありますが、存在を顧客に依存しているため、それ自体が集合体の根ではありません。フィードバックコンストラクターで提供するロジックは、注文にcustomerIdがあり、フィードバックは顧客に関連付けられている必要があることを示しているようです。意味あり。注文やフィードバックを顧客に関連させないようにするにはどうすればよいですか？さらに、サプライヤーは論理的に注文に関連しているようです（したがって、この集計内にあります）。

上記を念頭に置いて、必要な情報はすべてCustomer集約ルートですでに利用可能であり、ルールを間違った場所に適用していることが明らかになります。コンストラクターはビジネスルールを適用するためのひどい場所であり、すべてのコストで回避する必要があります。これは次のようになります（注：ファクトリーを使用する必要があるため、CustomerおよびOrde​​rのコンストラクターは含めません。すべてのインターフェースメソッドも表示していません）。

/*******************************\
   Interfaces, explained below 
\*******************************/

interface ICustomer
{
    public function getId() : int;
}

interface IUser extends ICustomer
{
    public function getUsername() : string;

    public function getPassword() : string;

    public function changeUsername( string $new ) : void;

    public function resetPassword( string $new ) : void;

}

interface IReviewer extends ICustomer
{
    public function provideFeedback( IOrder $order, string $content ) : void;
}

interface IBuyer extends ICustomer
{
    public function placeOrder( IOrder $order ) : void;
}

interface IOrder
{
    public function getCustomerId() : int;

    public function addFeedback( string $content ) : void;
}


interface IFeedback
{
    public function addContent( string $content ) : void;

    public function isValidContent( string $content ) : void;
}



/*******************************\
   Implentation
\*******************************/



class Customer implements IReviewer, IBuyer
{
    protected $id;

    protected $orders = [];

    public function provideFeedback( IOrder $order, string $content ) : void
    {
        if( $order->getCustomerId() !== $this->getId() )
            throw new \InvalidArgumentException('Customers can only provide feedback on their own orders');

        $order->addFeedback( $content );
    }
}


class Order implements IOrder
{
    protected $supplier;

    protected $feedbacks = [];

    public function addFeedback( string $content ) : void
    {
        if( false === $this->supplier->isOperating() )
            throw new \Exception('Feedback can only be added to orders if the supplier is still operating.');

        // could be any IFeedback
        $feedback = new Feedback( $this );

        $feedback->addContent( $content );

        $this->feedbacks[] = $feedback;
    }
}


class Feedback implements IFeedback
{
    protected $order;

    protected $content;

    public function __construct( IOrder $order )
    {    
         // we don't carry our business rules in constructors
         $this->order = $order;
    }

    public function addContent( string $content ) : void
    {
        if( false === $this->isValidContent($content) )
            throw new \Exception("Content contains offensive language.");

        $this->content = $content;
    }
}

はい。これを少し分解してみましょう。最初に気付くのは、このモデルがどれほど宣言的であるかです。すべてがアクションであり、ビジネスルールが適用される場所が明らかになります。上記のデザインは、正しいことを「行う」だけでなく、正しいことを「言う」ものです。

ルールが次の行で実行されていると誰が思い込むのでしょうか？

// this is a BAD place for rules to execute
$feedback = new Feedback( $id, $customerId, $order, $supplier, $content);

2番目に、ビジネスルールの検証に関連するすべてのロジックが、それらが関連するモデルに可能な限り厳密に実行されていることがわかります。あなたの例では、コンストラクター（単一のメソッド）が異なるモデルに対して複数の検証を実行しています。それはSOLID設計を壊します。フィードバックコンテンツに不適切な単語が含まれていないことを確認するためのチェックをどこに追加しますか？コンストラクタの別のチェック？異なる種類のフィードバックに異なるコンテンツチェックが必要な場合はどうなりますか？醜い。

3番目に、インターフェースを見ると、構成を通じてルールを拡張/変更するための自然な場所があることがわかります。たとえば、フィードバックの提供時期については、注文の種類ごとに異なるルールを設定できます。Orderは、さまざまな種類のフィードバックを提供することもできます。そのフィードバックは、検証のためのさまざまなルールを持つことができます。

また、多数のICustomer *インターフェイスも確認できます。これらは、ここで必要なCustomer集計を作成するために使用されます（おそらく単にCustomerと呼ばれるだけではありません）。この理由は簡単です。お客様がドメイン/ DB全体に広がる巨大な集約ルートである可能性が非常に高いです。インターフェースを使用することにより、1つの集合体（ロードするには大きすぎる可能性がある）を、特定のアクション（順序付けやフィードバックの提供など）のみを提供する複数の集合体ルートに分解できます。私の実装の集計は、注文とフィードバックの両方を行うことができますが、パスワードのリセットやユーザー名の変更には使用できません。

したがって、あなたの質問への答えは、集計は自分自身を検証する必要があるということです。できない場合は、モデルが不足している可能性があります。