天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

『ソフトウェアアーキテクチャ・ハードパーツ』読書会(ふりかえり)に参加してきた

connpassには立っていないのですが、『ソフトウェアアーキテクチャ・ハードパーツ』読書会のふりかえり会(読んだ内容の議論会)に参加してきたので、会の様子と感想を書いていこうと思います。

今回は第5章を対象にふりかえりをしていきました。

過去のイベント

yasashii-agile.connpass.com

モノリシックアプリケーションが分割可能かを測る指標

モノリシックアプリケーションが分割可能かを測る指標として、コードベースで共有されているソースコードのパーセントなどが適切な理由を話していきました。

この指標が分かることで、分割がシームレスにできるかやそもそも分割していいクラスなのか?という解釈が本書からできそうだという意見が出ていました。

XX管理クラス

「XXManager」といったクラス名を使用しないという話をしていきました。
参加者の皆さんは基本的には全員使わないという話で、以下のような話を関連して話し合っていきました。

  • クラス -> コンポーネント -> サービスそれぞれのレイヤーで抽象度が揃うような名前をつけるようにしている。クラスやコンポーネントレベルだと、XXManagerのようなクラスが入ってしまうと神クラス化しやすいし、サービスレベルだとシステムを管理するようなクラスと混同しやすいので管理という名前をあまり使わない
  • オーケストレーションするクラスなどにはManagerを使うこともあるかもしれない
  • サービスクラスにはXXServiceを使うことが多いので、XXManagerはあまり使わない

ビジネスとシステムの結合度のずれ

ビジネス側/システム側というように分断が起きているようなチーム構成の場合、ビジネス側が描く結合度とシステム側が描く結合度のずれが往々にして起きやすいよね、という話をしていきました。

その上で、両者の共通理解を揃えるような目的で本書は非常に有用な書籍になりそうだよね、という話が出ていました。

また、組織構造としてピラミッド型の構造を取っているとこのような事象が起こる引力が働きやすいよね、という話もしていきました。

このトピックは話が盛り上がりすぎて、ブログには書けないようなあまりにもリアルな話がしばらくの間続くことになり、とても楽しかったです笑

複数観点でコンテキスト領域を考える重要性

凝集度/セキュリティ/スケーラビリティ...といった複数の観点でコンテキスト領域を考える重要性が感じられる章だったという話をしていきました。

特にセキュリティの観点でコンテキスト領域を考えるとはどういうことがあるのか?という話や運用を軸にプロダクトを改善していった事例の話が出ていました。(セキュア・バイ・デザインで言われているような設計&実装をしていくという話や、SREの話など)

全体を通した感想

お昼のイベントはランチを食べながら軽い雑談をしたり軽い読書会をすることが多かったのですが、現場であったリアルな話が特に後半でできて満足できるイベントでした。

(お昼にやるかはさておき)もうしばらくふりかえり会は続けていく予定なので、残りの会も今日のような議論ができるように楽しんでいきたいと思います。