Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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


Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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


Slide 22

Slide 22 text

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


Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

ポステルの法則を理解して耐性のあるリーダー （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;
 }

Slide 25

Slide 25 text

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


Slide 26

Slide 26 text

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


Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

ポステルの法則を理解して耐性のあるリーダー （Tolerant Readers）をつかって破壊的変更を避け、 バージョンが必要ないようにします 4.13.1 最大限の見送り 必要な項目のみ定義する、や、フィールドの場所（構造） を曖昧にしておく、など、サービスとコンシューマの結合 を小さくすれば、リーダー(Reader)が関心のない変更を無 視することができる！！！ 耐性のあるリーダー（by Martin Fowler） •http://martinfowler.com/bliki/TolerantReader.html •https://uramoto.wordpress.com/2015/09/21/マイクロサー ビスのデザインパターン/

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

ポステルの法則を理解して耐性のあるリーダー （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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

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

Slide 118

Slide 118 text

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

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

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

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

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

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

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

Slide 145

Slide 145 text

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

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

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

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

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

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

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

Slide 154

Slide 154 text

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

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

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

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

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

Slide 159

Slide 159 text

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

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

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

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

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

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

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

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

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

Slide 169

Slide 169 text

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

Slide 170

Slide 170 text

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

Slide 171

Slide 171 text

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

Slide 172

Slide 172 text

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

Slide 173

Slide 173 text

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

Slide 174

Slide 174 text

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

Slide 175

Slide 175 text

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

Slide 176

Slide 176 text

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

Slide 177

Slide 177 text

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

Slide 178

Slide 178 text

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

Slide 179

Slide 179 text

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

Slide 180

Slide 180 text

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

Slide 181

Slide 181 text

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

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

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

Slide 184

Slide 184 text

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

Slide 185

Slide 185 text

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

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

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

Slide 189

Slide 189 text

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

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

変更したよ！

Slide 192

Slide 192 text

変更したよ！ やったー！

Slide 193

Slide 193 text

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

Slide 194

Slide 194 text

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

Slide 195

Slide 195 text

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

Slide 196

Slide 196 text

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

Slide 197

Slide 197 text

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

Slide 198

Slide 198 text

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

Slide 199

Slide 199 text

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

Slide 200

Slide 200 text

4.12 参照によるアクセス

Slide 201

Slide 201 text

4.12 参照によるアクセス

Slide 202

Slide 202 text

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

Slide 203

Slide 203 text

4.12 参照によるアクセス

Slide 204

Slide 204 text

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

Slide 205

Slide 205 text

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

Slide 206

Slide 206 text

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

Slide 207

Slide 207 text

4.12 参照によるアクセス

Slide 208

Slide 208 text

4.12 参照によるアクセス

Slide 209

Slide 209 text

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

Slide 210

Slide 210 text

4.12 参照によるアクセス

Slide 211

Slide 211 text

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

Slide 212

Slide 212 text

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

Slide 213

Slide 213 text

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

Slide 214

Slide 214 text

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

Slide 215

Slide 215 text

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

Slide 216

Slide 216 text

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

Slide 217

Slide 217 text

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

Slide 218

Slide 218 text

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

Slide 219

Slide 219 text

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

Slide 220

Slide 220 text

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

Slide 221

Slide 221 text

持ってないひとは是非！

Slide 222

Slide 222 text

ありがとうございました