私は現在、新しいエンタープライズシステムを設計中です。システムの目的は、顧客とのやりとり（イベント）を従業員に追跡、表示、通知することです。すべての追加のドメインオブジェクトはイベントのストリームから派生しているため、イベントソースパターンを使用して、すべての顧客インタラクション/イベントの元帳を収集しておくことは、非常によく似ているようです。しかし、私は、イベントソーシングに基づいたシステム全体が反パターンであると言った記事を見つけました。これはなぜでしょうか？なぜシステム全体のイベントソースはアンチパターンですか？
https://www.infoq.com/news/2016/04/event-sourcing-anti-pattern
記事は確かにDDDヨーロッパでグレッグの話「DDD、CQRS、イベントソーシングの10年」をまとめたものされ、これは間違いなくグレッグの話のポイントではありませんので、私は個人的に、この要約のタイトルを嫌う2016年
。基本的には、いつものようにそれはに依存します。
グレッグがシステムについて語るとき、彼はすべてを意味します。こののものは、DDDの言葉では、複数の限定されたコンテキストがあるコンテキストマップを持っています。通常、このコンテキストマップでは、サブドメインを識別できます。サブドメインは、さらに1つまたは複数のドメインをコアドメインとして識別することができます。
コアドメインがある場合、高度な技術に適しています。これは、集約のような従来のDDD戦術パターン、またはイベントソーシングのような「魅力的」なものでしょうか。実装は実際にはコンテキストのニーズに基づいている必要があります。
イベントソーシングに適しています。しかし、顧客/連絡先の管理や従業員の管理など、システムの他の部分について考えるかもしれません。これらの詳細はどこかから来るべきです。これらはCRUDの候補者かもしれませんか？この場合、あなたのコアドメインが従業員と顧客の間のやりとりを追跡することになっている場合、Event-Sourcingとシステムの他の部分を使用して、あまり高度な技術を使用してその部分を構築することができます。
外部システムを含めて、コンテキストマップにすべての部分を入れておけば、システムという単語は、記事とトークの意味になります。
ありがとうございました。私はシステム全体のより大きな視野の中で有界コンテクストマップの役割を完全に理解していませんでした。まず、これらの境界にある状況を打ち破り、彼の声明を誤って理解したことに気がつきました。 – hypno7oad
記事は、グレッグ・ヤングの話を引用しています。関連セクションが表示されるhere.
YoungはCRUDが「すべての種類のクレイジーな使用例」を隠し、例として誤植を修正すると説明しています。
また、イベントソースシステムでは分析が高価になる可能性があることも指摘しています。
一般に、システムの特定部分の真実のソースとして不変のイベントを持ち、読み取りモデルから分離されていると、コストがかかり、盲目的に採用すべきではありません。
Youngは、「イベントドリブンのようなもの」はCQRS /イベントソースではなくトップレベルのアーキテクチャになると示唆しています。
"システム"の意味によると思います。すべての組織ソフトウェアをシステムと呼ぶならば、おそらくアンチパターンです。 –