MSA読書会３章•マイクロサービスの境界について考える•マイクロサービスの欠点を最大化し、利益を最小化させる•次章以降への導入の位置付けかな？

3.1 MusicCorp•レコードのオンライン販売

3.2 優れたサービス•疎結合• 他のサービスに影響なしに変更し、デプロイできること

• →マイクロサービスの本質• サービス間の情報を共有しない、知らない

•高凝集• 何かを変更したい時、変更すべき箇所が一箇所に集まっている

•「変更」がポイント

3.3 境界づけられたコンテキスト• 在庫と経理

• 二つのモデル• 外部に共有するモデルと共有しない隠れモデル

• 明示的な境界によって強制される特定の債務• 「異なるコンテキストに存在する意味が全く異なる同じ名前のモデル」

• プロセス境界内でモジュール分割する。それがマイクロサービスの候補• 時期尚早な分割は危険• サービス境界がドメイン内の境界づけられたコンテキストと一致し、マイクロサービスが境界づけられたコンテキストを表していれば、疎結合で高凝集。• エバンズから

• https://www.infoq.com/jp/news/2015/06/dddx-microservices-boundaries

補足　「境界づけられたコンテキスト」• 問題• 「複数のモデルはどんな巨大プロジェクトにも存在する。だが、別々のモデルに基づくコードが組み合わされると、ソフトウェアはバグの温床となり、信頼できなくなり、理解しにくくなる。…コミュニケーションは混乱し始める」→それゆえ、「モデルが適用されるコンテキストを明確に定義する。アプリケーションの用途、チーム編成、コードベースやDBのスキーマなどの観点から定義」モノリシックなアプリケーション内部の区分け。コンテキスト内部で一貫性を保つことができる。異なるコンテキスト間の統合は腐敗防止層を置いて、汚染を防ぐ。But, 相互の関係を見失わないような工夫も必要。継続的統合やコンテキストマップ

ディスカッション•自分たちのシステムでは、境界づけられたコンテキストはどこまで意識的に定義されているだろうか。• できているとしたら、それによるメリットは？• できていないとしたら、それによるデメリットは？• （そもそも、本当に「境界づけられたコンテキスト」を意識する必要があるのか）

•自分たちが意識している「境界づけられたコンテキスト」はマイクロサービスの候補としてしっくりくるか。

サービス分割のあれこれ• 3.4 ビジネス機能• データの観点からではなく、提供する機能の観点から考える• CRUDはダメ。。。

• 3.5 ずっと亀の下• サービスは入れ子になる。• どの粒度でマイクロサービスにするか、組織の観点も重要

• 3.6 ビジネス概念での観点での通信• サービスインタフェースもビジネス観点から。組織内の書類形式を考えることと同じ。DDDにおける公表された言語？

3.7 技術的境界•オニオンアーキテクチャ• データベースアクセスをサービス化→フロントとバックエンドの両方のサービスを頻繁に変更　性能問題

•技術的境界で区切るのもメリットもあり• 性能とか

•第一条件ではなく、第二条件

補足　•分散システムは根本的に異なるものである。• ネットワークは信頼できない• ある程度の遅延は常に発生する• ネットワークはセキュアではない• ネットワーク構成は変化する• 管理者は複数である• 転送コストはゼロでない• ネットワークは一様ではない「実践ドメイン駆動設計」より

分散システムは複雑性をもたらす。。。

補足• JJUG CCC 2016 Spring F-5セッション• 分割方針として、 API化、外部から呼べること。 21スライド目• http://www.slideshare.net/takakiyo/javaapi-62250041

ディスカッション• CRUDサービスやオニオンアーキテクチャは本当に良くないのか？•良くないとしたら、何が本当に問題なのか•アンチパターンによるマイクロサービス化にメリットはあるか

3.8 まとめ

感想•基本となる考え方はモノリシックのモジュール化と変わらない•分散システムの複雑性によるデメリットよりもデプロイや基盤技術の選択も含めてチームの自律性を認めるメリットがあるとマイクロサービス？• thoughtworksの連中だってこと忘れないこと•サービス境界も変化していくのはあり？• Restだけじゃないよね• CQRSの例• https://youtu.be/qDNPQo9UmJA?t=1859

振り返り　次の章へ向けて•マイクロサービスについてわかった（と思っている）こと•マイクロサービスについてわからない（と思っている）こと•これから知りたいこと