TolerantReader パターンを一言でいうと
マーチン・ファウラーの記事TolerantReader - Martin Fowlerで言及されているパターンで、分散システムにおける受信データを読む際は、データ構造の多少の変更には影響を受けないように「寛容(Tolerant)」に作るべき、という設計原則である。
TolerantReader パターンの何が凄いのか？
1. 個々のマイクロサービスの独立した進化を促進する
マイクロサービス間の通信の受け手では、以下のケースのように「寛容な」作りをすることで、送信側の変更の影響を最小限に留めることができます。
- ケース1. 受信したデータの中で、使用しないものは無視する
以下のXML1の「telephoneNumber」が必要ではなかったら、読み手は無視すべきである。
<pre class="code" data-lang="" data-unlink=""><customer>
<firstname>Sam</firstname>
<lastname>Newman</lastname>
<email>sam@magpiebrain.com</email>
<telephoneNumber>5551234 5678</telephoneNumber>
</customer>- ケース2. データ構造を意識しないつくりにする
先の受信データをパス付きで「/customer/firstname」のように読み取ると、以下のXML2のようにデータの階層構造の変更があった場合に、やはり、受信側が動作しなくなります。
<pre class="code" data-lang="" data-unlink=""><customer>
<naming>
<firstname>Sam</firstname>
<lastname>Newman</lastname>
<nickname>Magpiebrain</nickname>
<fullname>Sam "Magpiebrain" Newman</fullname>
</naming>
<email>sam@magpiebrain.com</email>
</customer>このようなことに備えてXPathの「//firstname」のような特定のパスを指定しない方法で読み取れば、変更の影響を受けない、ということです。
このような原則を適用することで、あるマイクロサービスを変更しても、他のマイクロサービスへの影響を最小限に抑えることができます。そのことが、個々のマイクロサービスが独立して進化させていくことができるようになるのです。
2. 分散システムの先人の教えを引き継いでいる
マーチン・ファウラーの文章でも引用されていますが、「TolerantReader」は、「ポステルの法則」(「ロバストネス原則」3とも呼ばれる)の考えを引き継いでいます。
be conservative in what you do, be liberal in what you accept from others.
(送信するものに関しては厳密に、受信するものに関しては寛容に。)
-- Jon Postel
「ポステルの法則」は、ポステルがTCPを規定した RFC793で記載されました。インターネットのような分散システムを構築するうえでの重要な考え方となります。マーチン・ファウラーは、その重要性を認識しており、自身の「TolerantReader」にその考えを引き継いだのです。
結局、TolerantReader パターンとは
マイクロサービスが個々に独立して進化することを促進してくれる設計原則です。この原則をチーム内で共有しておけば、無用な軋轢を事前に避けることができかもしれません！
参考
- TolerantReader - Martin Fowler
「TolerantReader」パターンの原典です。 - ジョン・ポステルのロバストネス原則とマイクロサービス - Qiita
「TolerantReader」だけではなく、「ロバストネス原則」に関してもわかりやすく説明してくれています。 - これなら分かる！マイクロサービス（活用編）～そのアーキテクチャを実現するデザインパターンを一気に学習
設計パターンがわかりやすく解説されています。
参考文献
脚注
- 書籍「マイクロサービスアーキテクチャ」(p73)から抜粋。↩
- 書籍「マイクロサービスアーキテクチャ」(p74)から抜粋。↩
- 「ロバストネス原則」は、オブジェクト指向開発の文脈で語られる「ロバストネス分析」とは、別のものです。「ロバストネス」(robustness)とは、「堅牢性」という意味です。「ロバストネス原則」も「ロバストネス分析」も、堅牢なシステムを構築するための教えではありますが、内容は随分と違います。「ロバストネス原則」は、インターネットのような分散システムにおけるノードのあるべき振る舞いの原則を示したものです。一方、ロバストネス分析は、UML策定メンバーの１人であるイヴァー・ヤコブソンが、ユースケース等の要求モデルを分析する際に、システムを「バウンダリ」「エンティティ」「コントロール」の3つに分けて行うことで、より要求モデルを堅牢にしよう、という考え方です。まったく内容は異なりますが、「システムは堅牢である必要がある」という点では、共通する価値観であるといえます。ちょっと無理矢理感が漂いますが、、、↩
