第三回マイクロサービスアーキテクチャ読書会（後半）

第３回MSA読書会（後半） #MSA読書会

こんにちは！しょぼちむ (@syobochim)

後半のもくじ 4.11 マイクロサービスの世界における DRYとコードの再利用のリスク 4.12 参照によるアクセス 4.13 バージョニング 4.14 ユーザインターフェース
4.15 サードパーティーソフトウェアとの統合 4.16 まとめ

4.15 サードパーティーソフトウェアとの統合 4.16 まとめ ⇦ここからいくよ！

4.16 まとめ４章で言いたいこと •いかなる代償を払ってもデータベース統合を避けます •RESTとRPCとの間のトレードオフを理解し、RESTをリクエスト / レスポンス統合の優れた出発点と積極的にみなします •オーケストレーションよりもコレオグラフィを選びます •ポステルの法則を理解して耐性のあるリーダー（Tolerant
Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします •ユーザインターフェースを合成レイヤと考えます

Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします •ユーザインターフェースを合成レイヤと考えますこっちは前半部分

Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします •ユーザインターフェースを合成レイヤと考えますこのふたつについてまず説明していきます！

Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします •ユーザインターフェースを合成レイヤと考えます 4.13 バージョニング 4.14 ユーザインターフェース

4.15 サードパーティーソフトウェアとの統合 4.16 まとめこのあたりは最後に時間があれば

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします ‐について書いてあるのが

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13 バージョニング P73 マイクロサービスに関して話すたびにバージョニングをどのように行うかを訊かれました。
人々は「いつかはサービスのインターフェースを変更しなければならない」という当然の心配をし変更の管理方法を理解したいと思っている。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13 バージョニングこの問題を分割し、対策を説明していきます。 •コンシューマ(クライアント)の心持ち •サービスの心持ち •バージョンの意味付け
•サービスのバージョンアップ方法

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送り「サービス側の変更に影響されないように気をつけましょう」というコンシューマ側の心持ちのはなし

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送り「サービス側の変更に影響されないように気をつけましょう」というコンシューマ側の心持ちのはなし影響されない＝バージョンが必要ない

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送り最初から破壊的な変更を避けることが、破壊的変更の影響を減らす最善の方法です。クライアントに優れた振る舞いを推奨し、そもそもサービスと密結合にならないように
しましょう。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送りたとえば、メールサービスが‑のレスポンスをおくってくるとき <customer>  <firstName>Sam</firstName> 
<lastName>Newman</lastName>  <email>[email protected]</email>  <telephoneNumber>555-1234-5678</telephoneNumber>  </customer>

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送り telephoneNumberをつかわないコンシューマーが、こんなクラスを作っていて、リクエストに来ている項目をそのままバインディングするソースを書いちゃうと。。。 public
class Customer {  public String firstName;  public String lastName;  public String email;  public String telephoneNumber;  }

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送りメールサービス「メール送信にtelephoneNumberって使ってないよね？消します。」 <customer>  <firstName>Sam</firstName> 
<lastName>Newman</lastName>  <email>[email protected]</email>  <telephoneNumber>555-1234-5678</telephoneNumber>  </customer>

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送りメールサービス「メール送信にtelephoneNumberって使ってないよね？消します。」「えっ」 <customer> 
<firstName>Sam</firstName>  <lastName>Newman</lastName>  <email>[email protected]</email>  <telephoneNumber>555-1234-5678</telephoneNumber>  </customer>

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送りメールサービス「メール送信にtelephoneNumberって使ってないよね？消します。」「えっ」➡ クラス修正が必要
（telephoneNumberを消すことがコンシューマの破壊的変更になっちゃう。） public class Customer {  public String firstName;  public String lastName;  public String email;  public String telephoneNumber;  }

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送りたとえばfirstNameとlastNameの階層構造を明確に推測している場合『customer >
firstName』『customer > lastName』『customer > email』 public class Customer {  public String firstName;  public String lastName;  public String email;  }

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送りメールサービス「項目増えてきたから階層構造にしてみたわー。」 <customer>  <naming> 
<firstName>Sam</firstName>  <lastName>Newman</lastName>  <nickName>Magpiebrain</nickName> <fullName>Magpiebrain</fullName> </naming> <email>[email protected]</email>  </customer>

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送りメールサービス「項目増えてきたから階層構造にしてみたわー。」「えっ」 <customer> 
<naming>  <firstName>Sam</firstName>  <lastName>Newman</lastName>  <nickName>Magpiebrain</nickName> <fullName>Magpiebrain</fullName> </naming> <email>[email protected]</email>  </customer>

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送りメールサービス「項目増えてきたから階層構造にしてみたわー。」「えっ」 ➡
クラス修正が必要（項目名は変わってないのに。。。） public class Customer {  public Naming naming;  public String email;  } public class Naming {  public String firstName;  public String lastName;  … }

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送り必要な項目のみ定義する、や、フィールドの場所（構造）を曖昧にしておく、など、サービスとコンシューマの結合を小さくすれば、リーダー(Reader)が関心のない変更を無視することができる！！！

耐性のあるリーダー（by Martin Fowler） •http://martinfowler.com/bliki/TolerantReader.html •https://uramoto.wordpress.com/2015/09/21/マイクロサービスのデザインパターン/

XPath •https://msdn.microsoft.com/ja-jp/library/ ms256086(v=vs.120).aspx

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送りポステルの法則 https://ja.wikipedia.org/wiki/ジョン・ポステル「送信するものに関しては厳密に、受信するものに関しては寛大に」
「人にやさしく、自分にきびしく」

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.1 最大限の見送り「サービス側の変更に影響されないように気をつけましょう」というコンシューマ側の心持ちのはなし

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.2 破壊的変更の早期の把握「コンシューマへの変更の影響を出す前に検知しましょう」というサービス側の心持ちのはなし

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.2 破壊的変更の早期の把握「コンシューマへの変更の影響を出す前に検知しましょう」というサービス側の心持ちのはなし影響を出さない＝バージョンが必要ない

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.2 破壊的変更の早期の把握コンシューマ駆動契約で問題を早期に検出する

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.2 破壊的変更の早期の把握コンシューマ駆動契約の詳しいはなしは７章を発表する人にお任せしますが。。。

こんポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.2 破壊的変更の早期の把握コンシューマー（ヘルプデスク）が期待する動作を顧客サービスがテストとして書いて動作を保証する。そのテストが、コンシューマーとの契約になる。ヘルプデスクの
コンシューマ駆動契約のテスト範囲

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.2 破壊的変更の早期の把握サービスやライブラリをテストすることで、この動きはまずいぞ！ (契約違反だぞ！すなわち破壊的変更！！) というのを検知することができる。
※テストを書いているので、破壊的変更の特定も簡単！！

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.2 破壊的変更の早期の把握破壊的変更が入ったら、 •顧客サービスが破壊的変更を回避する •破壊的変更を受け入れてコンシューマの担当者たちと相談する

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.2 破壊的変更の早期の把握「コンシューマへの変更の影響を出す前に検知しましょう」というサービス側の心持ちのはなし

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにしますこのあたりが、「バージョンが必要ないようにします」という話でした。それでもコンシューマがサービスの破壊的なバージョニングに対応しなきゃいけないことが
絶対にあるじゃあ、どう運用していけばいいんだろう？

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.3 セマンティックバージョニングの利用コンシューマとサービス間で「変更の種類をわかりやすいようにしましょう」というルールを作るはなし

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.3 セマンティックバージョニングの利用変更の種類をわかりやすくする手段のひとつがセマンティックバージョニング http://semver.org/lang/ja/

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.3 セマンティックバージョニングの利用 MAJOR.MINOR.PATCH •MAJOR：後方互換性のない変更 •MINOR：後方互換性のある新機能の追加 •PATCH：既存機能にバグ修正が行われた場合
※他にも細かいルールがサイトには書いてあるよ。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.3 セマンティックバージョニングの利用使っている側はバージョンを見るだけで、変更にどの程度の影響があるのかを判断できる。明確なルールがあることで、サービスを提供する側と受け取る側の情報交換の
プロセスを簡略化することもできる。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.3 セマンティックバージョニングの利用コンシューマとサービス間で「変更の種類をわかりやすいようにしましょう」というルールを作るはなし

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 異なるエンドポイントの共存サービス側の変更によってコンシューマーになるべく変更を与えないようにしましょう（影響を制限する）

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 異なるエンドポイントの共存 •独立してリリースできるようにしたい。 •コンシューマーに同時アップグレードを強要したくない。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 異なるエンドポイントの共存 •独立してリリースできるようにしたい。 •コンシューマーに同時アップグレードを強要したくない。そうだ！エンドポイントの新旧両方のバージョン
を公開すればいいんだ！！！

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 異なるエンドポイントの共存 •提供する機能のエンドポイントを拡張して新旧両方をサポート！ •コンシューマの移行が済んだらAPIを縮小して古い機能を取り除く！

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 異なるエンドポイントの共存 •新しいインターフェースをできる限り早く公開できる •コンシューマに移行する時間を与える

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 異なるエンドポイントの共存ルーティングする手段 •リクエストヘッダのバージョン番号 ‣URIが不透明になるので、クライアントにURI テンプレートをハードコードしなくて済む
•URIのバージョン番号（/v1/customer と /v2/ customer） ‣物事が非常に明確になり、リクエストのルーティングを簡素化できる

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 異なるエンドポイントの共存ただし、バージョンが3つ以上になると辛いエンドポイントに合わせたコードとテストを用意しなきゃいけないのでメンテが大変になっちゃう。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 異なるエンドポイントの共存サービス側の変更によってコンシューマーになるべく変更を与えないようにしましょう（影響を制限する）

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.5 複数のサービスバージョンの同時使用「わざわざエンドポイントを分けるってめんどくさくない？二つのバージョンのサービスを用意しておけばいいじゃん
時間が出来たら移行しよう」

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.5 複数のサービスバージョンの同時使用

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.5 複数のサービスバージョンの同時使用古いコンシューマのトラフィックを旧バージョンにルーティングし新しいバージョンのトラフィックを新バージョンにルーティングする

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.5 複数のサービスバージョンの同時使用でもこれはアンチパターン

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.5 複数のサービスバージョンの同時使用サービス内の内部のバグを修正する必要があると 2つを直さなくちゃいけなくて大変振る舞いをミドルウェアのどこかか一連のnginxスクリプトに
配置しなければいけなくなるのでシステムの振る舞いを検証するのが大変データが旧バージョンと新バージョンのどちらで作られたものかがわからない

配置しなければいけなくなるのでシステムの振る舞いを検証するのが大変データが旧バージョンと新バージョンのどちらで作られたものかがわからないコードベースを分岐させるのはやめよう。（http://12factor.net/ja/）

配置しなければいけなくなるのでシステムの振る舞いを検証するのが大変データが旧バージョンと新バージョンのどちらで作られたものかがわからない

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.5 複数のサービスバージョンの同時使用短期間だけこの方法をとるのはいいよ。ブルーグリーンデプロイやカナリアリリースなどをする場合はOK （詳しくは7章を担当する人が話してくれます。）
ブルーグリーンデプロイ http://www.atmarkit.co.jp/ait/articles/1312/03/news033_2.html カナリアリリース http://www.nttdata.com/jp/ja/insights/trend_keyword/ 2013061301.html

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.5 複数のサービスバージョンの同時使用ローリングメンテナンス http://www.itmedia.co.jp/im/articles/ 0701/26/news124.html みたいに、数分や数時間だけバージョンを
共存させることはありますよね。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.5 複数のサービスバージョンの同時使用 Netflixでも古いコンシューマを変更するコストが高すぎる場合、特にレガシーデバイスがまだ APIの旧バージョンに縛られている場合に備えて「慎重に」利用している。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 と 4.13.5を比べてみよう 4.13.4

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 と 4.13.5を比べてみよう 4.13.4 エンドポイントは複数のバージョンに対応しているが、
裏のロジックは1つ。古いバージョンのリクエストを受け取ったエンドポイントは、新しいバージョンの形式に変換してから裏のロジックに流す。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 と 4.13.5を比べてみよう 4.13.5

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13.4 と 4.13.5を比べてみよう 4.13.5 エンドポイントのみならず、裏のロジックも新旧存在する。
つまり、アプリケーションそのものが 2つある状態。

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにしますバージョンのお話はここまで！

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします 4.13 バージョニング説明したこと •コンシューマ(クライアント)の心持ち •サービスの心持ち •バージョンの意味付け
•サービスのバージョンアップ方法

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにしますディスカッションします？

ポステルの法則を理解して耐性のあるリーダー（Tolerant Readers）をつかって破壊的変更を避け、バージョンが必要ないようにします •現場で「バージョンが必要ないように」って実現してますか？ •まだしてないひとは、どうすればいいと思いますか？ •サービスとコンシューマ間の情報共有で何か工夫してますか？

ユーザインターフェースを合成レイヤと考えます ‐について書いてあるのが

ユーザインターフェースを合成レイヤと考えます 4.14 ユーザインターフェースすべてのマイクロサービスを顧客が理解できるものにまとめる場所

ユーザインターフェースを合成レイヤと考えます 4.14 ユーザインターフェース前まで GET / POST経由でサーバ側で処理。サーバ側プログラムがページ全体を描画してクライアントブラウザに送信。クライアントブラウザは少しの処理しかしない。

ユーザインターフェースを合成レイヤと考えます 4.14 ユーザインターフェース最近 JavaScriptがもろもろやってくれる。

ユーザインターフェースを合成レイヤと考えます 4.14.1 デジタルへ向けて最近は、 Web・モバイル・デスクトップアプリケーション・ウェアラブル端末など、いろんな媒体でWebサイトが見られている。

ユーザインターフェースを合成レイヤと考えます 4.14.1 デジタルへ向けて顧客がどのように対話するか正確には予測できないかつデバイスによって見たいコンテンツも違う

ユーザインターフェースを合成レイヤと考えます 4.14.1 デジタルへ向けてそこで、ユーザインターフェースを合成レイヤだと考える。提供するさまざまな機能を組み合わせる場所

ユーザインターフェースを合成レイヤと考えます 4.14.2 制約でも、ユーザインターフェースっていろんな種類があるから、ただまとめればいいわけでもないですよね？

ユーザインターフェースを合成レイヤと考えます 4.14.2 制約たとえば、それぞれのデバイスの使い方はタブレットでは右クリックできないスマホでは親指だけで操作したいみたいに。

ユーザインターフェースを合成レイヤと考えます 4.14.2 制約中核のサービスは同じでもそれぞれのインターフェースがもつ制約にサービスを適用させる必要がある。

ユーザインターフェースを合成レイヤと考えますじゃあ、どういう風に webサイトを作っていけばいいんでしょう？

ユーザインターフェースを合成レイヤと考えますじゃあ、どういう風に webサイトを作っていけばいいんでしょう？ ※いろんなサイトを例に出したりしますが「そうじゃないぞ！！！」という方（中の人とか）がいたら教えてください。。。

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成まずはよくあるサイトの作り方 UIにAPI呼び出しを行わせてすべてをUIコントロールにマッピングする

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない P81 段落１つめ

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない P81 段落２つめ

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない P81 段落３つめ

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない。 •小さな変更でも、複数のチームに変更リクエストをおこなわないといけなくなる。
•サービスの担当者たちはサービスのユーザへの見せ方に関わらない。

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成顧客サービス担当者「サービス変更したからUI もあわせて変更して！」 UI担当者「はーい」

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成顧客サービス担当者「サービス変更したからUI もあわせて変更して！」 UI担当者「はーい」レコメンデーションサービス担当者「サービス変更したからUIもあわせて変更して！」

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成顧客サービス担当者「サービス変更したからUI もあわせて変更して！」 UI担当者「はーい」レコメンデーションサービス担当者「サービス変更したからUIもあわせて変更して！」 UI担当者「いま顧客サービスの方を修正しているから。。。」

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成顧客サービス担当者「サービス変更したからUI もあわせて変更して！」 UI担当者「はーい」レコメンデーションサービス担当者「サービス変更したからUIもあわせて変更して！」 UI担当者「いま顧客サービスの方を修正しているから。。。」
レコメンデーションサービス担当者「こっちの方が急いでるんだけど…。」

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成つらい

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成顧客サービス担当者「この項目の桁数を変えようと思う。画面への影響ないか確認して。」

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成顧客サービス担当者「この項目の桁数を変えようと思う。画面への影響ないか確認して。」 web UI担当者「わかったよ。」モバイル UI担当者「わかったよ。」

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成顧客サービス担当者「この項目の桁数を変えようと思う。画面への影響ないか確認して。」 web UI担当者「わかったよ。」モバイル UI担当者「わかったよ。」顧客サービス担当者「リリースしたいんだけど
確認おわった？」

確認おわった？」 web UI担当者「終わった」モバイル UI担当者「まだだよ。」

確認おわった？」 web UI担当者「終わった」モバイル UI担当者「まだだよ。」リリースできない

確認おわった？」 web UI担当者「終わった」モバイル UI担当者「まだだよ。」

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成つらい

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない。

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成１つの画面を表示するために３つのサービスを呼び出さないといけない ❶ ❷ ❸

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成たとえば（１）ヘルプデスクアプリではWeb画面で見る顧客記録を全部見たい移動店舗ではモバイルアプリで見る店舗で買ったことがある顧客記録だけ見たい

ユーザインターフェースを合成レイヤと考えます 4.14.3 API合成たとえば（２） http://qiita.com/api/v2/docs#ユーザレスポンスでいろんな情報が返ってくる web画面で見るならいいけどスマホで見るときはここまで情報はいらないかも

ユーザインターフェースを合成レイヤと考えますでは、欠点を補うためにはどうしていけばいいでしょう

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成サービスにUIの部品を直接提供させその部品を集めてUIを作成する

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成 UIコンポーネント

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成たとえば http://syobochim.hatenablog.com/ twitterのところがwidgetになっている

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成たとえば http://syobochim.hatenablog.com/ twitterのところがwidgetになっている急遽つけたので、かなり雑です。。。

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成たとえば http://syobochim.hatenablog.com/ twitterのところがwidgetになっているデザインを決めているのはブログの管理者でもはてなさんでもなく twitter！

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成たとえば http://syobochim.hatenablog.com/ twitterのところがwidgetになっているデザインを決めているのはブログの管理者でもはてなさんでもなく twitter！ widget系が多い。
このモデルを適用しているサイトは少ない

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成サービスを変更するチームが UI部品の変更も行う

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成サービスを変更するチームが UI部品の変更も行う ‑ 変更をすぐに公開できる

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成ただし、注意があります

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成ユーザエクスペリエンス（ユーザ体験）を他のサービスと一貫させないと使いにくくなっちゃう。

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成ユーザエクスペリエンス（ユーザ体験）を他のサービスと一貫させないと使いにくくなっちゃう。「えっ、この部品は更新するために下にスクロールすればいいのに、こっちの部品は更新ボタンを押すのか。。。」

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成ユーザエクスペリエンス（ユーザ体験）を他のサービスと一貫させないと使いにくくなっちゃう。「えっ、この部品は更新するために下にスクロールすればいいのに、こっちの部品は更新ボタンを押すのか。。。」わかりにくい！！！！

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成そういうのを回避するためにリビングスタイルガイドを作りましょう

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成そういうのを回避するためにリビングスタイルガイドを作りましょう HTMLやCSS、画像といった資産を共有してある程度の一貫性を持たせる http://getbootstrap.com/javascript/ 動くものがあると簡単にイメージを共有できる

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成解決できるか確信が持てない大きな課題

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成解決できるか確信が持てない大きな課題サービスが提供する機能がウィジェットやページにきちんと収まらないことがある。

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成解決できるか確信が持てない大きな課題サービスが提供する機能がウィジェットやページにきちんと収まらないことがある。対話の形式が横断的になるほどこのモデルが当てはまる場合が少なくなり単なるAPI呼び出しに戻る場合がある

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成こういうことが苦手ゼクシィは需要がタブごとに別れている http://zexy.net/ （タブを各サービスとする）

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成こういうことが苦手ゼクシィは需要がタブごとに別れている http://zexy.net/ （タブを各サービスとする）サイトの右上の検索機能を使うと各サービスを混合した結果が出てくる
（対話の形式が横断的）

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できないでもこのふたつは解消できていない

ユーザインターフェースを合成レイヤと考えます 4.13.4 UI部品合成この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない『4.14.5 フロントエンド向けのバック
エンド(BFF)』はここの二つの話

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) サーバ側集約エンドポイントの APIゲートウェイを用意する！ https://www.ogis-ri.co.jp/otc/hiroba/ others/SilliconValley5/

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF)

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) APIゲートウェイでサービスを順番に呼び出して結果を組み合わせる

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) APIゲートウェイでサービスを順番に呼び出して結果を組み合わせるサーバとの通信が一回で済む

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) https://twitter.com/kawasima/status/ 753483914954485761 APIゲートウェイでサービスを順番に呼び出して結果を組み合わせるサーバとの通信が一回で済む

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) AWSにも API Gateway管理サービスがある http://docs.aws.amazon.com/ja_jp/ apigateway/latest/developerguide/ welcome.html

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) でもサーバ側エンドポイントの振る舞いが多くなりすぎたとき大惨事になることがある

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) でもサーバ側エンドポイントの振る舞いが多くなりすぎたとき大惨事になることがある全てのサービス向けの１つの巨大なレイヤをもつのは影響が大きくなりすぎるので問題

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) たとえば一つのサービスに破壊的変更があったときブラウザもモバイルもネイティブアプリもすべてのクライアントに影響が出ちゃう APIゲートウェイ自体が死んだ時の影響もすごく大きい

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) BFF(フロントエンド向けのバックエンド) Backends For Frontends http://samnewman.io/patterns/architectural/ bff/

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF)

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) ここが分かれた

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) サーバーに組み込まれたユーザインターフェースの部品

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) 各デバイスごとの表示を細かくわけましょう！

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) デバイスごとに表示を変えることができるたとえばGoogle

ユーザインターフェースを合成レイヤと考えます

ユーザインターフェースを合成レイヤと考えます検索結果がwebとスマホで少し違う

ユーザインターフェースを合成レイヤと考えます検索結果がwebとスマホで少し違う ‑ 「スマホ対応」のサイトを優先

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) 特定のユーザエクスペリエンスの提供に特化した振る舞いだけを管理すること。さもないと入り込むべきではないロジックが入り込む恐れがある。

ユーザインターフェースを合成レイヤと考えます 4.14.5 フロントエンド向けのバックエンド(BFF) この方法の３つの欠点 •サービスの作成者とユーザインターフェースの作成者が違う •通信が多くなる可能性がある •デバイスごとにレスポンスを調整できない

ユーザインターフェースを合成レイヤと考えます 4.14.6 ハイブリッド手法 Webサイトは部品ベースの組み立てをしてモバイルアプリケーションはBFFを使うという企業もある。ユーザに提供する基盤となる機能の凝集性を維持することが必要

ユーザインターフェースを合成レイヤと考えます 4.14.6 ハイブリッド手法 https://www.thoughtworks.com/insights/blog/ bff-soundcloud ちなみに「4.15.5 ストラングラー（絞め殺し）パターン」についても書いてる

ユーザインターフェースを合成レイヤと考えます 4.14.6 ハイブリッド手法 4.15.5 ストラングラー（絞め殺し）パターン http://bliki-ja.github.io/ StranglerApplication/

ユーザインターフェースを合成レイヤと考えます 4.14.6 ハイブリッド手法 4.15.5 ストラングラー（絞め殺し）パターン http://bliki-ja.github.io/ StranglerApplication/ 昔からやっている「古いシステムを徐々に新しいシステムに移行していきましょうね」
のかっこいい言い方

ユーザインターフェースを合成レイヤと考えます 4.14.6 ハイブリッド手法 4.15.5 ストラングラー（絞め殺し）パターン古いシステムへの呼び出しをインターセプトする。呼び出しを既存のシステムにルーティングするか自分で記述した新しいコードに向けるかを
判断できる。

ユーザインターフェースを合成レイヤと考えます 4.14.6 ハイブリッド手法でも、ハイブリッドよりも。。。 BFFで作った層とクライアントで同じ言語、同じ実装で動かす isomorphic https://speakerdeck.com/koichik/isomorphic- survival-guide

ユーザインターフェースを合成レイヤと考えます 4.14 ユーザインターフェースおはなししたこと •API合成 •UI部品合成 •APIゲートウェイ •BFF(フロントエンド向けのバックエンド) •ハイブリッド手法 •isomorphic

ユーザインターフェースを合成レイヤと考えます 4.14 ユーザインターフェースではディスカッションタイム！ •いま紹介した手法のどれかをつかっていますか？ •いま業務で作っているサービスはどの手法を当てはめればいいと思いますか？

4.16 まとめまとめに関する説明が終わったのですがここ話してないです。 •4.11 マイクロサービスの世界におけるDRY とコード再利用性のリスク •4.12 参照によるアクセス •4.15
サードパーティソフトウェアとの統合 (4.15.5 ストラングラーパターンは話しましたが…)

4.16 まとめまとめに関する説明が終わったのですがここ話してないです。 •4.11 マイクロサービスの世界におけるDRY とコード再利用性のリスク •4.12 参照によるアクセス •4.15
サードパーティソフトウェアとの統合それぞれ、さらっと話ていきます！

4.16 まとめ •4.11 マイクロサービスの世界におけるDRY とコード再利用性のリスク •4.12 参照によるアクセス •4.15 サードパーティソフトウェアとの統合

4.11 マイクロサービスの世界における DRYとコードの再利用のリスク DRY (Don't Repeat Yourself) コードの重複を避けるようにすること

4.11 マイクロサービスの世界における DRYとコードの再利用のリスク DRY (Don't Repeat Yourself) コードの重複を避けるようにすることシステムの振る舞いと知識の重複を回避すること

4.11 マイクロサービスの世界における DRYとコードの再利用のリスク重複コードを抽象化して複数の箇所から呼び出すような共通ライブラリを作成する

4.11 マイクロサービスの世界における DRYとコードの再利用のリスクマイクロサービスとコンシューマを過度に結合すると危険！マイクロサービスの小さな変更がコンシューマへの不要な変更を引き起こしてしまうかも…！

変更したよ！

変更したよ！やったー！

変更したよ！やったー！えっえっえっ

4.11 マイクロサービスの世界における DRYとコードの再利用のリスク共有コードをサービス境界外で使うと結合の可能性を招きますログライブラリなど、外部から見えないものはOK

4.11 マイクロサービスの世界における DRYとコードの再利用のリスク一つのマイクロサービス内ではDRYをやぶらないけどすべてのサービスに渡るDRYの違反には寛大になろう!!! DRY違反よりもサービス間の結合の方が害があるよ

4.11.1 クライアントライブラリただし、一部の共通的な処理はそれぞれのサービスで実装するのではなくクライアントライブラリで共通化すると制御が簡単になることもある。

4.11.1 クライアントライブラリ Netflixのクライアントライブラリ https://github.com/Netflix/ribbon サービスの検出・故障モード・ロギングなど実際のサービス自体の性質とは関係ないところに対処する

4.12 参照によるアクセスドメインエンティティに関する情報を渡す方法について

4.12 参照によるアクセス

4.12 参照によるアクセスあるタイミングの顧客データ

4.12 参照によるアクセスここの顧客データは最新なの？

4.12 参照によるアクセス他のサービスから更新されているかも

4.12 参照によるアクセスじゃあどうすればいいの？

4.12 参照によるアクセス実際に使うタイミングで情報をとる

4.12 参照によるアクセス変更が入っても平気！

4.12 参照によるアクセス常に顧客サービスにアクセスして特定のCustomerに関連する情報を調べていると顧客サービスの負荷が大きくなりすぎる情報が新しいと考えられる期間を知らせるとキャッシングを大いに活用して負荷を減らせる

4.15 サードパーティソフトウェアとの統合自分では制御できないシステムに対する統合

4.15 サードパーティソフトウェアとの統合自分では制御できないシステムに対する統合 •Excel（オフィス生産性ツール） •OS •給与システムなどわざわざ構築するのはしんどい

4.15 サードパーティソフトウェアとの統合 4.15.1 制御の欠如ツールの拡張に使えるプログラミング言語は提供ベンダによる統合とカスタマイズの作業をチームに取り戻すことが大切

4.15 サードパーティソフトウェアとの統合 4.15.2 カスタマイズカスタマイズが可能なツールもあるでもカスタマイズのコストは新規に構築するよりも高くなってしまう場合があるので注意

4.15 サードパーティソフトウェアとの統合 4.15.2 カスタマイズ複雑なカスタマイズをするよりも組織のやり方を変更する方が理にかなっている

4.15 サードパーティソフトウェアとの統合 4.15.3 統合スパゲティツールとの統合方法も課題サービス間の統合方法を入念に検討することが重要

4.15 サードパーティソフトウェアとの統合 4.15.4 思い通りにする自分が制御するプラットフォーム上で全てのカスタマイズを行いツール自体を使うコンシューマの数を制限することで状況を自分の思い通りにする

持ってないひとは是非！

ありがとうございました

第三回マイクロサービスアーキテクチャ読書会（後半）

第三回マイクロサービスアーキテクチャ読書会（後半）

More Decks by syobochim

Other Decks in Technology

Featured

Transcript