第3回 Software Architecture: The Hard Parts 読書会@リモート

第3回 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] を読んでます
• 前回は +Chapter 3. Architectural Modularity まで
• 今回は Chapter 4. Architectural Decomposition から
• 次回は 2022-02-12（土）です。
  • 次回は Chapter 5. Component-Based Decomposition Patterns / Determine Component Dependencies Pattern から
  • 第4回 Software Architecture: The Hard Parts 読書会 - connpass

---

参加者トピック

• 前回の会、数年ぶりの焼き肉を堪能した
• SageMakerでちんたら動いていたML処理が、M1 Max Proの環境だと爆速だった
• SICP JavaScript Edition
• タイムゾーンを跨ぐ人たちとミーティングすると、議事録に記録する日付がずれて困る
• O'Reilly Japan - ベタープログラマ読んでる
• 大きめなリリースに手こずる日々
• 食中毒した セレウス菌食中毒（食中毒菌などの話） ｜公益社団法人日本食品衛生協会
• Bose QuietControl 30を使っていたのですが、Bose QuietComfort Earbudsも併用するようになりました
  • マイク性能がよさそう（本人には分からない）
  • Bluetooth接続デバイスの切り替えが面倒（QuietControl は同時に2デバイスの接続を維持できていた）
• YAPC::Japan::Online 2022があります
  • 申し込みには、Yahoo! JAPAN IDでログインが必要です
  • 2022-03-04 19:00～ 懇親会
    • チケット費用にTシャツ代金、お食事代金（配送）が含まれてる
    • お食事の配送日時とかも指定できる
  • 2022-03-05 14:00～ 本会
    • チケット費用にピザ代金（配送）が含まれてる
    • 配送日時が指定できる
• 技術書典12
• ｍＲＮＡワクチンの衝撃──コロナ制圧と医療の未来 | 種類,単行本 | ハヤカワ・オンライン
• SEからソフトウェアアーキテクトにジョブチェンジしていた

ディスカッション

ch04-1: Architectural Decomposition

• JDepend 古そうだけど最近だとどうなってるんだろう
  • SonarQube じゃないかなぁ
  • jQAssistant | Your Software . Your Structures . Your Rulesというのがよさそうだと思ってた
• Golang でカバレッジをチェックする、みたいな方法はあるのかな
  • The cover story - The Go Programming Languageで集めたデータを工夫すればよさそう
• GitHub - github/codeql: CodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security (code scanning), LGTM.com, and LGTM Enterprise みたいな検査方法もある
• SonarCloud 使ってる
  • 危険なコーディングを発見してくれるのがよい
• Dependency Graph
  • Visualizing Codebases
  • Introducing the Open Source Insights Project | Google Open Source Blog

ch04-2: Component-Based Decomposition

• 戦術的フォークの考え方は、普段のリファクタリングでもやってそう
• ADRの書き方に問題がある
  • どの判断が決定に貢献してるのか、定量的に分からない
  • 後から読んだ人が分かるようになっているほうがいい
• 「モノリシックアプリケーションをマイクロサービスへ移行するときは、踏み石としてサービスに基づくアーキテクチャへの移行を考えた方がよい。」
  • 本当に？
  • 「サービスに基づくアーキテクチャ」=「モジュラーモノリス」だったら納得できる

Chapter 5. Chapter 5. Component-Based Decomposition Patterns

• コンポーネントに基づく分解の段階
  • Identify and Size Components Pattern
  • Gather Common Domain Components Pattern
  • Flatten Components Pattern
  • Determine Component Dependencies Pattern
  • Create Component Domains Pattern
  • Create Domain Services Pattern
• 「コンポーネントの境界が明確」だから「コンポーネントに基づく分解」をすることにしたはずだけど、そのままドメインサービスにするのではなく、分解、整理、統合をやり直すのはなるほどなという気持ち
• 「アーキテクチャストーリー」って一般的な言葉？
  • 「テクニカルストーリー」「テクニカルユーザーストーリー」はある
• 1. ビジネス要件(ユーザーストーリー)が非機能要件に影響が及んだらユーザーストーリーとアーキテクチャストーリーは結びつく/ユーザーストーリーなしでアーキテクチャストーリーは成り立つか？
  2. 1. 成り立つはず。例えばソースコードのメンテナンス速度を向上させる、Shopifyのような開発者のドメイン学習時間を減らす、こういったモチベはアーキテクチャストーリー単体で成り立ちそう

Identify and Size Components Pattern

• コンポーネントを特定し、サイズを整えるパターン（段階）
• 伝統的なソースコード分析手法を使ってる
• 多言語だとどうするんだろう
  • それぞれで考えるしかない
• この段階で適合度関数を導入しちゃうのは意外
  • Flatten Components でやるのかと思ってた
  • 既存の状態をベースラインとして設定したいのではないか
    • ここより悪くなるなら良い方向に進んでいない、みたいな

Gather Common Domain Components Pattern

• 論理名前空間のノード名を分析すると、末尾が共通するなら共通機能が隠れていると判断出来る場合がある
• サイズを計測するより先にこっちをやるべきなのでは
  • 本来一緒になるべき機能が散らばっている場合がある
• こういう共通化を進めるのは誰？
  • 開発者がやるようになってきた
  • 開発者任せにしているとドキュメントが残らない場合があって難しい

Flatten Components Pattern

• Flatten Components パターンは、コンポーネントが他のコンポーネントの上に構築されるのではなく、フラット化されディレクトリ構造や名前空間のリーフノードとして表現されることを保証するために使用される。
  • なるほど、そういう意味だったんだ
• 例えば、.sharedcodeで終わる全ての名前空間の全てのステートメントの合計が、ソースコード全体の45%を占めている場合、分散アーキテクチャに移行すると共有ライブラリが多すぎて共有ライブラリの依存関係のためにメンテナンスが大変なことになる可能性がある。
  • 悪い予感を具体化する方法。賢い
• システム間連携コンポーネントを設計するとき、連携部分だけを別の誰かに任せないよう、全体が1つのコンポーネントになるようにした
  • いい話
• そういえば ss.shared みたいなコンポーネントが出てきてない
  • 例えばロギングのような横断的関心事

参考情報