「ソフトウェアアーキテクチャの基礎メモ」を読んでみた。 #412
「ソフトウェアアーキテクチャの基礎メモ」を読んでみたので感想メモです。
アーキテクトの仕事
アーキテクトの仕事はあまりイメージがついていなかったけれど、やんわりと輪郭がわかるぐらいにはなった気がする。
アーキテクトの仕事は一言で言うと「ドメインとエンジニアリングの知識をもって、アーキテクチャ特性のトレードオフを天秤にかけながら技術的な意思決定を行う」だと思った。
今年のDeveloper Summitの 継続的なサービス発展を支えるアーキテクチャと技術 / Developers Summit 2023 - Speaker Deck を読んだりしていても、Wantedlyの成長モデルの話が出てきていたので、アーキテクトの人はビジネスも一定理解している必要があるんだろうなと思った。
エンジニアリングにも詳しくないといけない。特定の言語・ライブラリに深く習熟しているというよりは、ある要件を実現するために幅広くソリューションを知っている必要がある。 技術をただ知っているだけではだめで、それぞれのPro/Conを説明できるレベルである必要がある。
また、プロダクトのコードがどのように動いているかも知っておく必要がある。 緊急ではないいくつかのタスクを担当する、などでプロダクトコードに慣れ親しむというやり方が紹介されていた。
技術による分離 / ドメインによる分離
ソフトウェアアーキテクチャとは、コードを分割するスタイルと言えるんじゃないかなと思った。コードを分割することで、可読性やデプロイ容易性・テスト容易性を上げられる。
分割のスタイルには「技術による分離」と「ドメインによる分離」がある。
Ruby on Railsで考えてみると、デフォルトのRailsプロダクトにはまず技術による分離しか存在しない。
例えば、決済に関わる一連の処理がどのモデルに書かれているかを app/models
下を見ただけでは分かりづらい。packwerkのようなGemを導入すると、決済パッケージを導入すればドメインによる分離が可能になる。
noteでのモジュラーモノリス化の取り組みは以下の記事などで紹介されている。
モノリシックRailsアプリケーションをモジュラモノリスへ移行しているnoteの事例 by Hiroya Shimamoto - Kaigi on Rails 2022
「再利用」よりも「複製」
この本で知った考えとして個人的におもしろいなと感じたのが、「再利用よりも複製」という考え方。
この考え方はモジュラーモノリス化を進めているときにも結構使っている気がする。例えば、パッケージ内からルートの lib のクラスやメソッドを使うというよりは、処理内容はある程度重複していても、パッケージ用の lib ファイルを作ったりする。 ルートにあるクラスに依存すると、そのクラスを変更する際の影響範囲が広くなる。パッケージ内に独自にクラスを置いてしまえば、影響範囲はパッケージ内で済み、変更の際のチームを超えたコミュニケーションなども基本発生しない。
コードを分割していくときには、DRYを捨ててあえて重複を選び、疎結合な実装にしていくのが大事なんだなと思った。