1

次の要件が存在するアプリに取り組んでいます。

  • ユーザーがフォームでデータを送信すると、これは「下書きコピー」として保持されます。
  • 一方、承認者はそれを読み、何らかのアクション (承認、拒否など) を実行します。
  • 承認者がドラフト コピーを承認すると、それは契約となり、両者は法的に拘束されます。元の送信者は、戻ってドラフト コピーを変更し、再送信できます。承認者が最新バージョンを承認すると、既存の契約はこの新しい契約に置き換えられます。

私が苦労しているのは、私たちのプロジェクトに DDD を採用しようとしているのに、本当に「正しいと感じる」解決策がないということです。私たちは皆、最新の DDD にかなり慣れていないため、適切なモデルを見つけるのは非常に困難です。

これは文書管理の問題ではありません。提出者が作業するドラフト コピーは常に 1 つだけあり、どちらの当事者も編集できない契約が存在する場合があります (編集は、ドラフト コピーを変更して再提出することによって実行されます)。これらの目的のために、これら 2 つのドメイン概念のフィールドは同一です。

ここで適用できる設計パターンまたは DDD フレンドリーなソリューションはありますか?

4

1 に答える 1

2

ここで何が必要なのかわかりませんが、EventSourcingパターンを確認することをお勧めします。ドメイン オブジェクトの変更を追跡するのに非常に役立ちます。マーティン・ファウラーをフォロー:

イベント ソーシングにより、アプリケーションの状態に対するすべての変更が一連のイベントとして確実に保存されます。これらのイベントを照会できるだけでなく、イベント ログを使用して過去の状態を再構築し、遡及的な変更に対処するために状態を自動的に調整する基盤としても使用できます。

そしてグレッグ・ヤング:

2 つのモデルを持つことのもう 1 つの問題は、必然的により多くの作業が必要になることです。オブジェクトの現在の状態を保存するコードを作成し、イベントを生成して発行するコードを作成する必要があります。これらのことをどのように行っても、イベントを公開するよりも簡単なことはありません.現在の状態を保存することを完全に簡単にするドキュメントストレージと言う何かがあったとしても、それをプロジェクトに持ち込む努力はまだあります.

—グレッグ・ヤング—

ユーザーが「ドラフト コピー」を送信すると、イベントが発生し、EventSourcing. 別のユーザーが作成した別の「ドラフト コピー」は、EventSourcingオブジェクトによってキャプチャされ、新しいバージョンとしてマークされます。それをどのように変えるかは、DDDを適用する必要があります。ドキュメント オブジェクトはDomainオブジェクトであり、識別子を持ちます。

エンティティの各バージョンの状態をクエリして更新しEventsourcing、オブジェクトのバージョンを取り戻すのは簡単です。

MSDNEventSourcingから詳細を参照できます。

この助けを願っています。

于 2013-05-20T04:47:11.850 に答える