第2回 Software Architecture: The Hard Parts 読書会@リモート
第2回 Software Architecture: The Hard Parts 読書会 - connpass
- JavaEE勉強会の読書会
- 開催場所はDiscordのjavaee-study-jp
- Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani さんの Software Architecture: The Hard Parts [Book] を読んでます
- 前回は
Sysops Squad Saga: Understanding Quanta
まで - 今回は
+Chapter 3. Architectural Modularity
から - 次回は 2022-01-22(土)です。
- 次回は
Chapter 4. Architectural Decomposition
から - 第3回 Software Architecture: The Hard Parts 読書会 - connpass
- 次回は
参加者トピック
- 古い MacBook を下取りに出したら 100 円だった
- バッテリーが膨張してるとかそういう理由がある
- ageHa / スタジオコーストをクローズすることになりました。|Masaaki Obari|note
- クローズイベントあったけど自重(諦めた)
- 多摩美術大学が、誰もが参加できる“デザインの大学”を期間限定開校。50の新たなデザイン領域を知る、講義プログラム公開|多摩美術大学のプレスリリース
- 東京ミッドタウン・デザインハブ第94回企画展「Tama Design University」 by 多摩美術大学 TUB
- ZeBrand の話が印象的だった 東京ミッドタウン・デザインハブ第94回企画展「Tama Design University」 by 多摩美術大学 TUB
- ブランドを立ち上げるところを機械学習とかの技術を駆使して支援するという考え方
- GopherCon 2021
- オンラインは無料
Generics!
が気になった- Robert Griesemer & Ian Lance Taylor | Generics! - YouTube
- Architecture overview | Fleet
ディスカッション
+ch03: Architectural Modularity
- 今日の世界で生き残るためには、ビジネスはアジャイルでなければなりません
- しかし、ビジネス・ステークホルダーが迅速な意思決定と方向転換を行うことができても、企業のテクノロジー・スタッフがその新しい指示を変化をもたらすほど迅速に実行できない場合があります
テクノロジーがビジネスと同じ速さで動けるようにするには(逆に言えば、テクノロジーがビジネスを遅らせないようにするには)、アーキテクチャーにある程度のアジリティが必要です
大規模な技術スタックを移行した思い出
+Modularity Drivers
モジュール化を促進する動機。
- 競争優位性という目的を実現する要因は、可用性、スケーラビリティ、市場投入時間
- 市場投入時期を達成するというのは、アジリティを高めること
アジリティを高めるには、デプロイ容易性、テスト容易性、保守容易性を高めるとよい
Completitive advantage
- Availability
- Scalability
- Speed to market
- Agility
- Deployability
- Testablity
- Maintenability
- Agility
+Maintainability
-
- Sonargraph の開発、販売をしてる
ウィッシュリストドメインはアーキテクチャ全体に分散しているため、特定のドメインまたはサブドメイン(ウィッシュリストなど)のメンテナンスが難しくなっています。
一方、モジュラー・アーキテクチャーでは、ドメインやサブドメインを、より小さな、個別にデプロイされたソフトウェアのユニットに分割することで、ドメインやサブドメインの変更を容易にしています。
言うても変更範囲が見えているなら、モノリシックアプリケーション(レイヤーアーキテクチャ)であってもそんなに変更が負担になるとは思えない
マイクロサービスにしたところで、公開インターフェイスを変更するための調整コストが高いから、内部でどうにかするという判断をしてしまうことはある
- よくないことだと考えつつ
アプリケーションレベルの問題を解決する方針として、初手からモジュール化を進めるのはどうかと思う
- データベースを分割するのはとても大変な課題のはず
- 4、5年かかる
+Testability
「サービス間の通信が増加すると、テスタビリティは急速に低下します。」
- それでも安心感はあるのでやってしまうかなと
- 実際に通信せず、契約ベースのテストでOKにする、という判断はあるかもしれない
ランタイムに閉じた範囲でテスタビリティを高めるのはいい話
- ランタイム境界を越えるようだと新たな課題が出てきてしまう感じ
小さく分解すれば並列に作業を進められる、という話もある
GraphQL
- クエリする側、ロードする側のテストは容易になるとして
- 複雑なクエリのテストを効率的にする方法は無いだろうか
API ベースのエコシステムが流行った時代があった
Testing Strategies in a Microservice Architecture を思い出した。
+Deployability
2週間でも遅いと感じている
- トランクベース開発してるチームもある
「もしマイクロサービスを特定の順序で完全なセットとしてデプロイしなければならないのであれば、モノリスに戻して苦痛を省いてください。」
- 結構ある
+Scalability
マイクロサービスの設計、分割に失敗すると、非機能要求を実現できなくなりがち
- サービスの単位がドメインとしてはいびつになることがある
モノリシックアプリケーションのスケーラビリティはデータベースがボトルネックになっていたという理解
- マイクロサービスアーキテクチャにすることで、スケーラビリティを扱いやすくなったのかな
- Spanner 使ってるけど無限にスケールできるわけじゃない感じ
- Aurora だとどうなんだろう
バーストトラフィックに対応できる弾力性が実現できたとして、下流のサービスや後続のデータ処理パイプラインとかまで考慮できるかな
サービスが成長するとログはどんどん増えていくので、一括処理するところが大変になる
+Availability/Fault Tolerance
- 「決済処理が利用できなくなっても、システムのユーザーは商品の検索や注文を行うことができなければなりません。」
- そんな状態あり得る?
- 注文サービスが決済サービスを同期的に呼ぶ構造になっているなら、ちゃんと制御できることになる
+Sysops Squad Saga: Creating a Business Case
そうはならんやろう、という結論だった。