Pythonによるアーキテクチャパターン

パート II. イベント駆動アーキテクチャ

この話題のために「オブジェクト」という造語をずいぶん前に作ってしまったことを申し訳なく思っている。なぜなら、その方が多くの人がより少ないアイデアに集中できるからだ。

大きなアイデアは「メッセージング」である......偉大で成長可能なシステムを作る上で重要なのは、モジュールの内部特性や振る舞いをどうするかよりも、モジュールがどのようにコミュニケーションをとるかを設計することである。

アラン・ケイ

単一ビットのビジネスプロセスを管理するために1つのドメイン・モデルを書くことができるのは非常に良いことだが、多くのモデルを書く必要がある場合はどうなるのだろうか？現実の世界では、アプリケーションは組織の中にあり、システムの他の部分と情報を交換する必要がある。図II-1に示したコンテキスト図を覚えているだろうか。

この要件に直面すると、多くのチームはHTTP APIで統合されたマイクロサービスに手を伸ばす。しかし、気をつけないと、分散した大きな泥の玉という、最も混沌とした混乱をプロデューサしてしまうことになる。

パートIIでは、パートIのテクニックを分散システムにどのように拡張できるかを紹介する。ここでは、非同期メッセージパッシングによって相互作用する多くの小さなコンポーネントから、どのようにシステムを構成できるかを見ていく。

Service LayerとUnit of Workパターンによって、アプリを非同期メッセージプロセッサとして実行するように再構成する方法や、イベント駆動システムによって、アグリゲートとアプリケーションを互いに切り離す方法について説明する。

図 II-1. しかし、これらすべてのシステムは、一体どのように互いに会話するのだろうか？

以下のパターンとテクニックを見ていく：

ドメインイベント

一貫性の境界を越えたワークフローをトリガーする。

メッセージバス

あらゆるエンドポイントからユースケースを呼び出す統一された方法を提供する。

CQRS

読み取りと書き込みを分離することで、イベント駆動型アーキテクチャにおける厄介な妥協を回避し、パフォーマンスとスケーラビリティの向上を可能にする。

さらに、依存性注入フレームワークも追加する。これはイベント駆動型アーキテクチャそのものとは何の関係もないが、非常に多くの未解決の部分を整理することができる。