CQRS + Event SourcingアーキテクチャでのAdd / Create *コマンドの処理方法

イベントソーシングと一緒にCQRSパターンを使用して、最初のアプリケーションを実装します。集約ルートの作成を適切に処理する方法について疑問に思っています。誰かがCreateItemコマンドを送信したとしましょう。どのように処理する必要がありますか？イベントItemCreatedを保存​​する場所 新しいアイテムの最初のイベントとして？または、すべてのアイテムを集約し、そのイベントリストがItemCreatedイベントのみで構成される、何らかの種類のItemListエンティティが必要ですか？

Udi Dahan は、集約ルートを作成せず、常に何らかのフェッチメソッドを常に使用することを提案しています。しかし、新しいもので、IDが割り当てられていないものを取得する方法。私は背後にある考え方を理解しており、新しいオブジェクトは、それに応答するイベントがゼロで構成される状態を持つオブジェクトであると考えるのはかなり合理的です。しかし、どのように使用すればよいですか？私のような私のリポジトリに明確な方法を持っていなければならないgetNewItem()か、私の作るget(id)方法を受け入れてOptional<ItemId>代わりに？

編集：しばらく掘り下げた後、アクターを使用した前述のパターンの非常に興味深い実装を見つけました。作成者は、集計を作成する代わりに、新しく作成されたUUIDを使用して、何らかの種類のリポジトリからそれを取得します。このアプローチの欠点は、一時的な不整合状態を許容することです。またdelete、このようなアプローチでメソッドを実装する方法を疑問に思っています。削除済みイベントを集約のイベントリストに追加するだけですか？

私が収集するUdiの投稿のアイデアは、薄い空気からはどんなアイテムも現れないということです。（ほとんど）常に何か、より具体的には、何らかのドメイン操作があり、それによってアイテムが作成されました。ユーザーが実際にサイトに登録した訪問者から生まれたUdiの例のように。その時点およびその境界コンテキストで、Visitorは集約ルートであり、IPアドレスによって取得されます。この訪問者は、Registerと呼ばれるドメイン操作を通じて、この時点でユーザーである新しい「アイテム」を作成します。同じことが前のステップにも当てはまります。これは別の制限されたコンテキストです。リファラーはARであり、URLによって取得され、訪問者が生まれるBroughtVisitorWithIpと呼ばれるドメイン操作を持ちます。

Udiは削除についても非常にうまく書いています：http : //www.udidahan.com/2009/09/01/dont-delete-just-dont/。主なアイデアは、何も削除しないことです。キャプチャしたいドメイン操作が常に背後にあります。注文が削除されるのではなく、キャンセルされるように。それを読んで、それは非常に良い投稿です。

ここでの両方のアカウントの主なポイントは、DDD、特にイベントソーシングを行うことで、決して直接的なCRUD操作を行うべきではないということです。何らかのデータを挿入、更新、削除するだけで本当に背後にドメイン操作がないという状況に陥った場合、DDDとEvent Sourcingはその境界コンテキストに適していない可能性があります。単一の境界コンテキストが1つの原則に準拠している限り、これら2つを自由に組み合わせることができます。このように、CRUDスタイルの境界付きコンテキストはデータベースに行を作成し、それが別の境界付きコンテキストのエンティティおよび集約ルートになり、ARを取得できるようになり、ARを作成する必要がなくなります。