背景
もともと私がよくお世話になっている、モローさんが所属するキッカケさんで
よくお話しさせていただいているキャメロンさんという方から、
８月に「アーキテクチャ系のイベントをやってください」とお願いされたのがキッカケでした。
もともと設計やアーキテクチャ系のイベントにはよく参加していたものの、
オフラインのイベントで自分が主催側に回るという機会は今回初でした。
いろんなアーキテクチャ系のイベントに参加していて思うことは、
開発系の畑でのアーキテクチャ、セキュリティ系の畑でのアーキテクチャ、
などがかなり分断されて考察されているというように感じていたため、
今回のイベントでは、
・開発畑のアーキテクト
・セキュリティコンサルさん
・マイクロサービスなどの大規模システムのQAをされている方
というかなり広義のエンジニアの方々を招待させていただきました。
イベント自体は休憩や質疑応答も込みで5時間ほどのイベントでしたが、
内容が非常に濃密であったことと、異色のコラボであったと感じています。
今回はその濃密すぎる内容を１つの記事でまとめきれないと感じたため、
複数回に分けて、議事録及びアウトプットとして記事に残しておきます。
今回は米久保さんの登壇内容のアウトプットです。
米久保さんによるアーキテクト的戦略思考
米久保さんとは設計系のイベントでお会いしたことや、
吉祥寺.pmのMagnoliaさんの開催された、設計ナイトでよくお話ししたご縁と、
以下の書籍をプレゼントいただけたことからお声がけさせていただきました。
ちなみにこのアーキテクトの教科書は、難易度自体は比較的初歩～基礎レベル
になっており、初級者～中級者のアーキテクト向けな内容から
サービスレベルのマクロな量子になっても普遍的に使える設計原則など、
本質を抑えられるような構成になっていると感じ、新品で譲っていただいたのに、
ボロボロになるまで読み込ませていただきました。
逆コンウェイ戦略
わたしは、完全に逆コンウェイの考え方を誤解していることにこの日気づけました。
ちなみによく誤解しがちな逆コンウェイの考え方が以下。
わたしもこれで考えてしまっていました。
逆コンウェイとは先にあるべきアーキテクチャを考えて、それに合わせて組織構造、コミュニケーションパスの設計を行うというものではない。
アーキテクチャと組織は常に相互に力学を及ぼし合うもので運命共同体。
ともに同時並行で仮説検証しながら、組織とアーキテクチャを同時に進化させていく。
ちなみにこれは進化的アーキテクチャの考え方に通じる。
個人的に質問した内容
DBが物理的に分かれたモジュラーモノリス
お恥ずかしながらモジュラーモノリスは、以下のようにDB部分で物理的に１つで結合しているものだと思っていた。
しかしながら、アーキテクチャ関連の翻訳をしている島田さんも、
米久保さんもDBが物理的に分離されていて、アプリ部分で1つに結合しているものを
モジュラーモノリスと呼んでいる。
その理由は以下のようにお二方共におっしゃっていた。
データ部分が一番蜜結合になりがち問題
データが物理的に結合していることによるリスクが大きい以上、
明らかに「そこにデータのコンテキスト境界はれるよね」って所は最初から物理的に別のDBとして分けておく。
そしてアプリ側でトランザクションの境界を跨いだりしないように疎な結合にしておくことで、すぐにマイクロサービス化できるような状態にしておく。
アプリ側ならば違反のチェックの担保もしやすく、データが物理的に結合している状態よりも、リスクを抑えられるからとのこと。
ただし、トランザクション境界を考える際に、
複数のモジュールにまたがらないようにモジュールを分割しなくてはいけない。
コンポーネントの粒度ごとのポリシー
参加者の方から、設計の際のポリシーに関するご質問が上がったので、
各マクロサイズ～ミクロサイズのコンポーネント(ミクロサイズのコンポーネントをJavaだったらパッケージのことを指すとする)に対してのポリシーと、監視すべきメトリクスの関係に関して質問させていただいた。
その結果、より解像度が上がった内容として、以下の結果が得られた。
そのコンポーネントの設計ポリシーが定義されることで、自ずと見るべきメトリクスも決まる。
逆にどんなメトリクスを監視したらいいのかわからないといった場合には、
まだそのコンポーネントの設計ポリシーが決まっていない可能性が高い。
下位のコンポーネントは、上位のコンポーネントのポリシーを継承する形でないといけない。
これはリスコフの置換原則を考えたら当然のことである。
逆に下位で「そのメトリクスは集められない」っていう制約があれば、
それを上位に反映するなど、具体と抽象レイヤーの行き来によるポリシー決めと
それによるメトリクス定義と改善活動が求められる。