マイクロサービスアーキテクチャをざっと読んだので、分かる範囲で感想を書く
学んだことがまだ整理できていないのですが
自分用にメモを残す意味合いも込めて書いておきます。
読んだ本
概要
全て理解するためには、サーバサイドやバックエンドの知識も必要になるため
その辺の内容は読み飛ばしました。(いつか読めるようになりたい。)
フロントエンドで普段開発している自分にとって心に残った内容をPickUpしてアウトプットしようと思いました。
マイクロサービスは2週間で書き直せるもの
Jon Eaves (@joneaves) | Twitterさんの言葉らしいです。
マイクロサービスとは、十分に小さく、ちょうど良い大きさを示すことが多いようです。
マイクロサービスってそもそも何なんだろうとか、サーバサイドだけの話かと思っていたのですが
モバイルアプリケーションでも、アーキテクチャを採用して責務を分割していくことが多いため、通じるところは多いのかなと感じました。
APIの考え方
最近だと、iOSDCでMicroViewControllerについての発表がありました。
これを採用することによる副次的な効果として
UI部品単位で非同期処理を行いたい画面(通信を行いたい場合など)に対して
責務をUI部品内に収められることが非常に良いのかなと感じました。
また、APIについて学ぶ際には、以下の記事がとても参考になりました。
本を読んで感じたこと
- なんで疎結合を求めるのか？？
既存のコードに対する技術がある程度枯れてきているから、MicroServiceの概念が生まれてきているのかな？と感じました。
密結合な方が参入する上でのハードル感は低いはずなので、新しいハードやバックエンドの技術が出てきたら、密結合な方向にシフトしていきそうだなと感じました。
新しい技術⇨密結合、枯れた技術⇨疎結合 を求める流れがあるのかな？と思いました。
- 様々な組織において、どう運用していくのか
月並みですが、組織の構成や求められているサービスなど、再現性のない組織に対して、適切なアーキテクチャを考えることは、すごく大変なことだなと感じました。
この本に書いてある通り、銀の弾丸はないという言葉がすごく刺さりました。
- 責務の分割を知らない人、興味のない人がいた場合、どう伝えるか
自分はアーキテクトについて考えることが結構好きだなと感じました。
一方で、そこまでアーキテクトについて考えることが好きでないエンジニアもいるかなと感じています。
組織の中では、興味がそこまでない人をどう巻き込んでいくのかも重要なのかなと思いました。
TODO
