1

私は、大規模な従来の ASP Web アプリケーションをドメイン駆動設計の ASP.Net MVC に変換中です。私のドメインの多くは DDD に適していますが、純粋な DDD アプローチが適切でない状況に遭遇し続けています。たとえば、私のアプリケーションの読み取り側は、書き込み側とは大きく異なります。別の読み取りモデルを作成し、簡易バージョンの CQRS を実装しました (イベント ソーシングなし、別のデータベースなし)。もう 1 つの問題は、データベースの一括操作でした。問題ありません。それはサービスとして実装されています。ここに私の現在の困惑があります。私たちのシステムでは、ユーザーはシステムに変更を加えることができ、その変更は将来のある日付で有効になります。これに対応するために、発効日まで保留中の変更を保存するデータベース テーブルがあります。発効日に、自動化されたタスクが実行され、実際のデータベース更新が実行されます。更新タスクにはドメイン ロジックを含めることができるため、その部分は DDD に適合し、問題はありません。何が起こっているかを視覚化するために、保留中の更新を処理するクラスを次に示します。

public class PendingChanges
{
    public int EntityID {get; set;}
    public string FromTable {get; set;}
    public string DetailField {get; set;}
    public string NewValue {get; set;}
    public DateTime EffectiveDate {get; set;}
    public DateTime EnteredDate {get; set;}
    public int UserID {get; set;}
    public string UserName {get; set;}
    public string UserArea { get; set; } 

   // Business logic and validation here? 
}

ご覧のとおり、これはさまざまなデータベース テーブルの更新を処理できる汎用クラスです。基本的に、更新されているデータベース列、列の新しい値、列が属するテーブル、有効日、およびいくつかのログ データが格納されます。

ここに私の質問があります: 保留中の更新を収集して保留中の更新テーブルに格納するロジックは、ドメイン オブジェクトとしてモデル化する必要がありますか、それともサービスなどの他の方法で処理する必要がありますか?

別の言い方をすれば、PendingChanges 自体が独自のドメイン ロジックを持つドメイン エンティティなのでしょうか。変更が行われているエンティティとは別に、PendingChanges に適用されるビジネス ルールがいくつかあります。たとえば、UserArea を構成するものは、検証は言うまでもなく、FromTable の有効な値と同様にビジネス ルールと見なすことができます。

それとも、異なるドメイン オブジェクト間で再利用できるため、PendingChanges は値オブジェクトですか? その場合、PendingUpdatesService を使用する方が理にかなっていますか?

4

1 に答える 1