Mathias Verraes氏が一連のブログ記事を投稿して、自身が仕事で出会った、有用な分散システムのパターンについて説明している。目的は、パターンをその有用なコンテキストとともに識別し、命名し、文書化することだ。その中で氏は、誤った状況で使用することが、パターンをアンチパターンにする場合の多いことを強調している。
DDD Europeの創業者兼コンサルタントであるVerraes氏は、現時点で16のパターンを、デカップリング、汎用メッセージング、イベントソーシングという３分野に定義した上で、各パターンについての問題と解決策を、時には例や実装を含めて説明する。
"Completeness Guarantee"は、プロデューサから送信されるドメインイベントセットの定義を目標とする部分と、プロデューサの状態をコンシューマが再現可能であることを必要とする部分との分離パターンである。多くの場合において、イベントはコンシューマのニーズに対応する形で定義され、あるいは変更される。そのため、時間が経つと、それぞれのイベントの目的が何であったのか、そもそもコンシューマがそのイベントを使っているのかどうか、理解することが難しくなる場合がある。完全性を実現するには、プロデューサにおいて状態が変化する都度、イベントが送信される必要がある。イベントには変更した属性のみが含まれ、それ以外は含まないのが理想的だ。このようにすることで、それぞれのイベントが何を意味し、何の属性を運ぶのかが明確になる。
"Passage of Time Event"は、サービス内のAPIを何らかのレートで呼び出す形式のスケジューラを、"DayHasPassed"や"MonthHasPassed"など、汎用的なドメインイベントを発行するスケジューラで置き換えることを目的とした分離パターンである。関心のあるサービスは、これらのイベントをリッスンして、必要なアクションを内部的に処理すればよい。Verraes氏に言わせれば、これは極めてリアクティブなアプローチだ。コマンドを送信して応答を待機するのではなく、スケジューラが、イベントがリッスンされているかどうかを気にせずに、時間に関するイベントを送信できるようになる。
"Explicit Public Event"は、イベントをプライベートイベントとパブリックイベントとに分離するためのパターンである。多くのサービスは、特にイベントソーシングを使用する場合、すべてのイベントを外部に公開するべきではない。理由のひとつは、サービスの外部APIが内部構造と密接に結合することによって、内部を変更する場合に、APIと他のサービスの両方の変更が必要になる可能性があるからだ。このパターンは、すべてのイベントをデフォルトでプライベートにして、パブリックのイベントを明確にマークすることで実装できる。その上で、プライベートイベントとパブリックイベントを、別々のメッセージングチャネルを使用して公開するのである。
"Segregated Event Layers"は、プライベートイベントとパブリックイベントをさらに分離する方法である。内部イベントをリッスンして、新たにパブリックイベントのストリームを送信するようなアダプタを用意することで、内部イベントは完全にプライベートになる。Verraes氏はこれを、パブリックイベント用の新たなイベントストリームが、専用のイベントタイプと名称を持った新たなコンテキスト境界になることによって、事実上の腐敗防止(anti-corruption)レイヤを構築する実装パターンである、と指摘する。
一部のコンシューマに対してのみ提供するイベントがある場合に使用可能なパターンのひとつが、"Forgettable Payloads"である。イベント内の機密情報は、その機密情報を含んだ、アクセス制限のあるストレージを指すURLに置き換えられる。同様のパターンとして、機密情報をリソースごとに異なるキーで暗号化する"Crypto-Shredding"がある。キーを削除することで、その情報にアクセスできなくなる。
"Decision Tracking"は、イベントソースを使用する場合に、決定の結果を格納する目的で使用される。適用期間の制限のように参照ルールが変更された場合、そのルール変更に追随せずにイベントが再生されると、得られる結果が異なる可能性がある。ひとつの解決策は、決定をイベントとして、その決定を引き起こしたイベントと合わせて保存することだ。Verraes氏はこのパターンが、バグの影響を緩和するためにも使用できる点に注目する。すべてのイベントを再生して、決定イベントのデータによる結果と比較することが可能であるためだ。
"Natural Language Message Names"は、メッセージ名に動詞を使用して表現力を高めることを推奨するパターンだ。自然言語を使用し、それをコードとアーティファクトに埋め込むことは、ドメイン駆動設計(DDD)の中心的な概念である。"Payment event"や"Invoice Paid"といった用語をドメインの専門家は使わない、という点にVerrases氏は注目する。そうではなく、彼らは"請求書が支払われた(Invoice was paid)"と言うのだ。"CustomerWasInvoiced"や"InvoiceWasPaid"といった名称をイベントに使用することを、氏は推奨する。コマンドには"InvoiceCustomer"や"FulfilOrder"がよいだろう。
これらの一連のパターンは出発点であって、他の開発者たちが見つけた、あるいは持っているパターンがあれば教えてほしい、と提案して、氏は一連の記事を締め括っている。氏の連絡先に関する情報は、氏のWebサイトにある。
Chris Richardson氏は、デプロイメント、通信スタイル、データ管理などのパターンに関するマイクロサービス用のパターン言語を開発した。