こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
- 会の概要
- 会の様子
- 成瀬さんの講演
- Q&A
- MLOpsを組み込んだアーキテクチャのベストプラクティスは?
- モジュラーモノリスとマイクロサービスの流行り廃りと採用基準は?
- 先の見えない状況で移行しやすさを考慮したアーキテクチャの選定は?
- アーキテクチャとプログラミングパラダイムには相関性、向き不向きがあるのか?
- 「クリーンアーキテクチャを実装する」みたいな誤解に関してどう考えるか?
- アーキテクチャにおけるハンマーをもつ人にはすべてが釘に見える問題に関して意見を聴きたい
- ソフトウェアアーキテクチャと組織体制や組織のケイパビリティの関係に関して
- 全体の開発の実力が低い組織で採用すべきアーキテクチャは?
- DDDを伸びしろ期に導入するとしたらどんなアプローチをとるか?
- アーキテクチャの知識の効率的なキャッチアップ方法
- マイクロサービスでのサービス間検証はどうやるのか?
- TODOに残していたけど実はチャレンジしたかった技術
- 会全体を通した感想
会の概要
成瀬さんが、いろいろなアーキテクチャがどういったもので、どういった場面に向いているのかを、各アーキテクチャごとに解説し、それぞれの選定時のポイントや採用時のハードルとその乗り越え方などについてお話してくれるイベントです。
会の様子
成瀬さんの講演
成瀬さんから、アーキテクチャに対する解説と私見に関して、自身が経験したアーキテクチャに関して主観的なトレンドの解説がありました。
バックエンドのアーキテクチャ
最初はヘキサゴナルアーキテクチャの解説がありました。
ヘキサゴナルアーキテクチャはバックエンドの基本だと成瀬さんは考えているそうで、アプリケーションを中心に見据えることができる点がメリットだというお話がありました。
次にレイヤードアーキテクチャに関して話がありました。
Evans本で有名なレイヤードアーキテクチャですが、昨今はDIが併用されるのが普通ということで、結果的にヘキサゴナルアーキテクチャに近い形になることが多いというお話がありました。また、広義な意味だとほぼ全てのアーキテクチャがレイヤードアーキテクチャになるということでした。
次にクリーンアーキテクチャの話がありました。
内容的に荒れやすいのであんまり話したくないそうですが笑、成瀬さんとしては(図をもとにしたクリーンアーキテクチャであるならば)ヘキサゴナルアーキテクチャと最終的にやりたいことは同じだというイメージがあるそうで、より思想の要素が強いのがクリーンアーキテクチャだということです。
併せて、クリーンアーキテクチャにおいて重要なのは依存のルールであるという話もありました。
GUIのアーキテクチャ
最初にMVC&MVC2の話がありました。
MVCが出たのはSmalltalkの時代のため、Webのためのアーキテクチャではないということで、MVC2が生まれたということです。
成瀬さんは、MVCやMVC2よりもmartin fowlerが提唱しているMVPのほうが好きだということで、その理由としてテスト容易性が優れている点が挙がっていました。
次にMVVMとMVWの説明がありました。
MVVMも一般的なアーキテクチャですが、成瀬さん的にはMとVを繋げる点にのみフォーカスした(=MとVさえ分けられればつなげ方は何でもよい)MVWが一押しだということです。
その他のアーキテクチャ
最初にマイクロサービスアーキテクチャの話がありました。
マイクロサービスアーキテクチャには公式定義はないそうですが、成瀬さん的にはデータストアを分けることをマイクロサービスアーキテクチャの要件として求めているということでした。
次にクラウドネイティブ(アーキテクチャ)の話がありました。
成瀬さんとしては、クラウドネイティブはスケーラビリティに注目したほうがいいと考えているそうで、スケーラビリティを上げることで達成したい即応性を担保するために弾力性や耐障害性を高める*1必要があるということでした。
CQRS+ES
上記のクラウドネイティブを実現するためには、成瀬さんイチオシであるCQRS+ESがおすすめだということでした。
本当はイベント一回分くらい使って話をしたいそうですが、インピーダンスマッチを避けられたりコマンドとクエリの異なる要件に応えられるのが良い点ということです。
Q&A
講演の最後はQ&Aのコーナーがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
MLOpsを組み込んだアーキテクチャのベストプラクティスは?
MLOpsを実践していないので答えられない...
モジュラーモノリスとマイクロサービスの流行り廃りと採用基準は?
マイクロサービスは一度バズワード化してしまったが、廃れて今は冷静に評価できる時期だと思っている。
なお、0/1ではなく、大規模化するとマイクロサービスに近いサービスになる印象はある。
個人的な採用基準としては、サービスを分けてしまう方が開発者に分別を求めない点で楽だと思っている。
先の見えない状況で移行しやすさを考慮したアーキテクチャの選定は?
アーキテクチャ変更は痛みを伴うので移行しやすさを考慮するのは難しいと思う。
メッセージ駆動までいければいいのだが8割方オーバースペックになるイメージ。
成瀬さん的には、今対処できるものと今予測できるものをベースに選定する。
アーキテクチャとプログラミングパラダイムには相関性、向き不向きがあるのか?
あくまでもイメージだが、OOPベースで提唱されたアーキテクチャは関数型に適応できるが逆は厳しいこともあるというイメージ。
CQRS+ESなど広い範囲を扱うアーキテクチャはそのまま適用できる印象がある。
「クリーンアーキテクチャを実装する」みたいな誤解に関してどう考えるか?
クリーンアーキテクチャに限らずレイヤードアーキテクチャの層の数の議論などでも同じことは起きていると思う。
誤解を防ぐというのは難しいと思うし、コードの冗長さに目をつぶれば盲目的に実装されたとしてもそこまで問題にはならないしないよりはいいかと考えている。(とはいえ冗長さは大問題)
アーキテクチャにおけるハンマーをもつ人にはすべてが釘に見える問題に関して意見を聴きたい
人を見るようにする。そのアーキテクチャで開発するメンバーのことや彼らが成長すべきかとかを考える。
あとは、個人の趣味でコードを壁打ちすると業務で試したい気持ちは薄れる。
ソフトウェアアーキテクチャと組織体制や組織のケイパビリティの関係に関して
まず役割を設定する。巻き込み力が高いメンバーをリーダーにする。
他にもイネイブリングチームを結成し、他チームのスキル獲得を支援する。
全体の開発の実力が低い組織で採用すべきアーキテクチャは?
バックエンドならクリーンアーキテクチャかなと思う。
DDDを伸びしろ期に導入するとしたらどんなアプローチをとるか?
DDDという言葉を使わない。そのうえであるときにしれっとこれってさ...みたいな感じで伝える。
アーキテクチャの知識の効率的なキャッチアップ方法
Xのタイムラインを追うのが効率的かと思っている。
マイクロサービスでのサービス間検証はどうやるのか?
API叩いてチェックします以上の話なら、結果整合性で実現している。
後続で失敗に気づいたらSagaパターンで補償トランザクションを実行する。
TODOに残していたけど実はチャレンジしたかった技術
Deepなリバースエンジニアリングや低レイヤーセキュリティ、OSなど。
会全体を通した感想
成瀬さんが楽しそうにアーキテクチャを話している姿が非常に印象的でした。
トレンドという言葉のイメージからは少しずれていたのですが、成瀬さんがどういうアーキテクチャを推しているのかやどういう思想が好きなのかは知れたので、その点はよかったかなと思います。
*1:詳細はリアクティブ宣言を参照