システムに単純さをもたらすために、小さなコンポーネント間のやり取りにイベントを使うことをRuss Miles氏が最近提案した。アジャイルソフトウェアのために、単純なイベント・ドリブンなコンポーネントをコーディングすることについて話した際の事である。
この話は、一ヶ月前の彼の講演イベントがシステムのアーキテクチャに単純さをもたらすのフォローアップである。そこで氏は、単純さについての彼の考えの基礎を築いた。アーキテクチャでは、小さなコンポーネントがお互いにイベントを交換することによって共同作業を行う。
この設計を使って、 Russが目指すのは、アプリやシステムが変わるスピードで、コンポーネントが変わることができるような状況にコンポーネントを置き、小さな変更が物事をめちゃくちゃにするような変化の摩擦を除くことである。
彼の最近の講演では、彼はコンポーネントに焦点を当て、単純さをコンポーネント間の結合を弱めるための原則として使っている。コンポーネントは易しいか、そうでないか？ 良いテストは、コンポーネントを移すのがいかに易しいかである。もし移動が難しければ、コンポーネントが複雑過ぎていることを示している。彼は複雑なコンポーネントを移動することを沢山のクリスマスツリーの電球と比較している。1つつまみ上げると、それに連れて全てがついてきてしまう。
複雑なコンポーネントを簡単にするために、彼は最初懸念や副作用を細かくして、これらを新しい小さなコンポーネントや関数に移動した。副作用の例としては、外界との統合がある。例えば、Russが関心ごとと捉えているロギングはインフラに移動するべきである。
イベントは、コンポーネント間でデータを転送するためのメカニズムである。これはコンポーネント間の結合場所をそのままにしている。送信部は、受信部を知っている必要があるからである。しかし、イベントディスパッチャを持つ中間のイベントドメインを導入することによりそれは除かれる。
イベントの最も簡単な形式は、あるコンポーネントから別のものに移動される、共有の不変クラスであるが、それもまた、結合を導入する。複雑さを減少させるためにRussがとる次のステップは、名前付きパラメータの形式でこのクラスをデータで置き換えることである。例えばキーと値のペアのマップである。
この設計の負のサイドは、間接参照である。Russは、それはそれ程複雑ではないと考えているが、潜在的な問題のいくつかを先延ばしすることで、それが表面化するかもしれない。これに対する答えは、広範なテストである。単体テストと統合テストの両方（2つのコンポーネント間の）である。