ドメイン駆動設計（DDD）は、私たちが取り組んでいるドメインに設計を近づける優れた技法だが、構造に焦点を当てすぎて、早期に設計を確定してしまうことが多すぎる。これはDDDの意図するところではない。それよりも、Russ Miles氏が「イベント - ファースト」でマイクロサービスを構築する利点を説明するなかで主張したように、ドメイン内のイベントから（設計を）始めるべきである。
Miles氏は、構造に焦点を当てることだけでなく、ユビキタス言語を特にドメインオブジェクトに集中させすぎていると考えている。より一層悪い事に、ドメイン境界を越えて再利用するために、ドメインオブジェクトを含むライブラリをも作り始めてしまい、異なる境界づけられたコンテキストが別々に発展することを事実上妨げてしまう。
氏の経験によれば、このアプローチは、エンタープライズ階層化アーキテクチャのデフォルトアーキテクチャスタイルとなっている。その理由は、作業を安易にするためであり、設計をシンプルに、または改善するためではない。これは、エンティティなどを、あるコンテキストではユビキタスであるものから、すべてのコンテキストにわたって標準的であるものへと変えてしまうことを引き起こし、DDDのアイデアとは直接矛盾する。
代わりに氏は、ドメインのなかで何が起きるか（イベント）から始めるべきだと主張する。その方が、ドメイン内のユビキタス言語を捕捉することに優れており、特にドメインエキスパートと共同作業をする場合には、ドメインを説明する最も簡単な方法である。氏はこのアプローチが、新しいシステムを構築する際にも既存のシステムを更新する際にも両方でうまくいくことを発見した。
イベントを扱う際にMiles氏が好む最初のステップは、Alberto Brandolini氏によって考案されたモデリングワークショップテクニックのEvent stormingである。基本的なアイデアは、ドメイン内で起こっている事柄（ドメインイベント）を探しながら、大きなモデリング面にタイムラインに沿ってステッカを並べ、これらのイベントを捕捉することだ。イベントを引き起こす可能性の例としては、ユーザのアクション、外部システムで起こっていること、時間の経過などがある。イベントは、ドメイン内の境界を見つけるのにも役立つ。関係する用語の異なる解釈は、境界を示すことができる。
複雑さのもう一つの原因は間違った仕事に間違ったモデルを使用していることである。 DDDは永続状態を扱うためにリポジトリパターンを持っているが、しばしば読み書きに同じモデルを使用する。これがもたらす利点の一つは一貫性であるが、ニーズが明確に異なる場合は、異なるモデルを使用して書き込みと読み込みを切り離すことで大きなメリットが得られる。
コマンドクエリ責務分離（Command Query Responsibility Segregation: CQRS）は、この切り離しを行うための手法のひとつである。
- コマンド（Command）は書き込みモデルで動作し、一貫した方法で、なるべく一つの集約だけを変更する。そして集約は1つ以上のイベントを生成する。Miles氏は、作成されたイベントは副作用がなく、コマンドの実結果であることに言及している。
- クエリ（Query）は、実行しようとしているクエリのために最適化された1つ以上の読み取りモデルを用いる。書き込みモデルによって発行され、読み取りモデルによって受け取られたイベントは、読み取りモデルが書き込みモデルの状態を反映するように更新されることを保証する。
イベントソーシングはCQRSの自然な拡張であり、集約によって発行されたすべてのイベントは、永続化され、集約の状態自体を格納する代わりに、その状態を再現するために使用される。状態を再現できるこの力は、氏によると、状態のもつ脆弱性を減らす方法のひとつである。
CQRSとイベントソーシングは、結果整合性のような他の複雑性をもたらす。CQRSという用語を生み出し、今日のイベントソーシングに対する関心を起こしたGreg Young氏は、（イベントソーシングは）トップレベルアーキテクチャではないと指摘する。氏によると、通常は限られた場所でのみ選択的に適用すべきであり、イベントソーシングに基づいてシステム全体を構築することはアンチパターンであると強調している。
Rate this Article
- Editor Review
- Chief Editor Action