多くのプログラミング言語に見られるif文には、2つの大きな役割がある。ドメインを誤ったデータから守るために入力を検証すること、そして、ドメインのビジネスロジックを処理することだ。残念なことに、私達はビジネスやドメインの観点からロジック中にif文を使用するリスクを管理するためにほとんど時間をかけないことを、Udi Dahan氏は先日アムステルダムで開催されたDDD Europe Conferenceにおいてプレゼンテーションのなかで主張した。
何かオンラインで購入する際、私達はさまざまな商品を見比べて、それらいくつかの詳細を確認する。買うものが見つかり、それをショッピングカートに追加することは、クエリ側から相互作用のコマンド側へ移動するということでもある。Dahan氏が考えるどんな種類のコマンドでも検討すべき重要な問いの1つは、コマンドが失敗する原因についてである。そして、Webサーバがクラッシュしたりデシリアライズに失敗するようなインフラストラクチャで処理されるべき技術的な障害と、買い物カゴに追加しようとしている商品がちょうど商品カタログから削除されている場合のような論理的な不具合を区別すべきであると強調する。
削除されたかどうかをチェックすることは、Dahan氏と顧客との仕事のなかによく現れる例である。氏にとって、削除された商品のような問題に対処するときの一歩は、プライベートなデータとパブリックなデータを区別することだ。コンテンツ管理システムにたとえると、ページやコンテンツを編集し、最後に公開ボタンを押して情報を公開するようなことである。プライベート側では、ユーザは何の問題もなく項目の追加や更新または削除を行え、最終的に満足したものを公開することができる。
パブリック側では、削除や削除のチェックをよりビジネス中心のロジックに置き換える必要がある。つまり、商品を削除すべき理由について更に考えなければならないということだ。例えば、もう販売されていない商品である。より良い方法は、何らかの論理削除または物理削除を使用する代わりに、商品を販売しないものとしてマークする特定のコマンドを作成することだ。
このような解決策の潜在的な問題の1つは、商品に販売終了のフラグが立てられる直前に、顧客が買い物カゴに商品を追加してしまうような競合状態である。その後、顧客が買い物カゴを精算したい場合に、その商品をもう購入することができない。Dahan氏にとって、このように問題を見ることは、非常に狭いデータ中心の小さなものの見方である。その代わりに、複数のアクターによる同時に同じオブジェクトを処理する典型的なシナリオとして、問題を説明する。
複数のアクターが同じデータを並行して操作するような協調的なドメインでは、氏はCQRSから考え始めるべきだと考えている。ドメインにCQRSを適用するときは、可能な限りシンプルにし、ドメインロジックに到達するコマンドを予め検証して失敗することがほとんどないように設計することを推奨している。これは、コマンドを処理する際に、たとえ競合状態で失うとしても、全体的なビジネス目標を達成するように準備する必要があることを意味している。多くの場合、これは結果整合性へと導くが、書き込みモデルと同期する読み取りモデルを持つような技術の類いではない。その代わりにビジネスの観点から導く。この例では、販売していない商品を顧客が買い物カゴに追加することについてである。
これを解決する方法の1つは、不活化やタイムアウトの際に、ひそかに買い物カゴから販売されなくなった商品を取り除くような長期プロセスを使用することである。結果的に商品はすべての買い物カゴから削除されており、これ以上販売されなくなる。
システムのなかを見渡すと、何らかの形で状態をチェックする多くのif文を見つけることになる。そのそれぞれについて、同じ状態を変更する可能性のある他のアクターが存在するかを自問すべきである。このようにして、潜在的な協調動作と長期プロセスの必要性を見つけることができる。もっともDahan氏は、あまりにも多くの長期プロセスを使うことに注意する必要があると言及し、それは銀の弾丸ではないことも強調している。
Rate this Article
- Editor Review
- Chief Editor Action