Vaughn Vernon氏はマイクロサービス内で不確実性をモデリングするためにリアクティブDDDを使用する

マイクロサービスとリアクティブモデルを使用することで多くの能力が得られるが、それらは同時に、ある時刻の物事の状態を知ることができない不確定性も共に持ち込む。開発者はメッセージ駆動システムに対してしばしば単純に思える疑問を持つことになる。
    ・誰かがメッセージを受け取ったのか?
・     ・メッセージに対し返信されたのか?
・     ￥√s同でメッセージが受信されたか?

Explore DDD conferenceの基調講演の中でVaughn Vernon氏は、このような問いを理解して結果に対応しようとすることはドメイン駆動設計の本質であると述べた。ユビキタス言語 を用いて境界づけられたコンテキストから構成されたシステムを記述することは、分散システムの複雑性に立ち向かう助けとなる。不確実性の概念、特に境界づけられたコンテキスト間のやりとりについては、ユビキタス言語の一部とすることが必要である。

実践ドメイン駆動設計とReactive Messaging Patterns with the Actor Model(未邦訳)の著者であるVernon氏は、良いコンテキストマップを作成することはプロジェクトにとって必要不可欠であると述べた。実践的に言えば、ビジネスのコアドメインには常に複数の境界づけられたコンテキストがあるはずであり、コンテキストマップにより境界付けられたコンテキスト同士の関係を可視化できる。コンテキストマップを書いているときは、RESTやRPCを用いるといったような技術の詳細ではなく、コンテキスト間におけるチームの関係を理解することに注力すべきである。Vernon氏の言葉を借りると、”どう統合するかよりも、誰と統合するかのほうがより重要である”。

Vernon氏は、リアクティブな振る舞いが含まれるリアクティブシステムに向かう傾向があり、そしてそれが単一のマイクロサービスを超えて拡大すると考えている。これは完全に新しいものではなく、彼はEric Evans氏がイベント処理パターンを重視する点において業界の先端を行っていたと述べた。その基本的なアイデアは過去に発生したイベントに反応すること、そしてそれからそのイベントが調和のとれた状態をもたらすということである。

マイクロサービスとリアクティブな振る舞いは不確実性をもたらす。これにはイベントがどういう順序で配送されるかに関する不確実性、そしてイベントが二度配送される可能性が含まれる。Vernon氏は”もしKafkaのようなメッセージングシステムを用いている場合であっても、イベントの順序を保って処理できるという仮定を置いているのであれば、それはごまかしである。任意のメッセージが順不同になる可能性が少しでもあれば、順不同となる全ての場合に備えておく必要がある”。

“任意のメッセージが順不同になる可能性が少しでもあれば、順不同となる全ての場合に備えておく必要がある” - Vaughn Vernon

Vernon氏は、我々が普段事象の適切な発生順を予測できるブロッキング命令やデータベースのロックのような概念に “毒されて”しまっているため、この不確実性は対処するのが困難であると考えている。リアクティブシステムにおいては、これらの長く信じられてきた考えは崩壊し始めている。開発者が本能的に不確実性を隠蔽するファサードを作成し、コードを伝統的でリアクティブでないソフトウェアのように動作できるようにするかも知れないということに対し、Vernon氏は正反対のアプローチを取るべきであると述べた。

彼は不確実性に対処する自身のアプローチを、”クエリを削減し、イベントを増やす”とまとめた。イベントにより時間軸上の特定の点で何が発生したかを把握することができる。現在のシステムの状態を知ることはできず、単にイベントが発生した時のシステムの状態、及び変化内容だけを知ることができるのでる。順不同の場合を含め、これらのイベントへの対応方法はビジネス上の決断であり、ユビキタス言語を用いて議論されなければならない。彼はPat Helland氏の論文であるLife Beyond Distributed Transactionsを引用した。”分散トランザクションを頼ることができないシステムでは、不確実性の管理をビジネスロジックとして実装する必要がある”。

Vernon氏は異なる不確実性の形態を示すいくつかのシナリオと、これらの各々を管理するための簡潔なコードサンプルを説明した。しかし、このコードはビジネス上の決断として何を行わなけばならないかを単に示しただけであることを彼は強調した。ビジネスにおいては不確定性について熟慮する価値観を重視すべきである。また、モデリングはビジネス上の意思決定者とオープンに決定すべきであり、ソフトウェア開発チーム内で決定すべきではない。不確実な状態を考慮しなくてよいようにファサードを作成すべきではない。むしろ最善を尽くしてその不確実性をモデリングするように努力しよう。