依存関係を明らかにする【リファクタリング入門4】 -

システムの依存関係を明らかにする方法を説明します。コンポーネントの結合度は、モノシリックなアーキテクチャの移行作業の実現可能性を決定する重要な要因です。この記事はリファクタリング入門記事の4番目の記事です。

参考記事

本記事は以下の二冊をもとに作成しています。アーキテクトを目指す人に対しておすすめの二冊です。

気になった方はこのページから購入していただけると自分に少しお小遣いが入るので差し入れとしてお願いいたします！

依存関係を明らかにする

モノシリックなアプリケーションを分散アーキテクチャに移行する際には次の3つの質問に答えられる様にしておく必要がある。

既存のアプリケーションは分解可能なのか？
必要なのはコードの書き直しなのか？それともリファクタリングなのか？
移行にかかる費用はどれくらいなのか？

例えば、CIOから次の様に質問が飛んで来るかもしれない

複雑なモノシリックアプリケーションをマイクロサービスにする移行作業にて、プロジェクトの初日CIOに次のことを尋ねられた。
「このプロジェクトの移行作業はゴルフボールサイズなのか？バスケットボールサイズなのか？旅客機サイズなのか？」
このときに、私はその質問に答えられなかったが、代わりに次の様に答えることにした。
「まだわかりません。ただ、そのぐらいの粒度のあらさで見積もりに答えるのであれば、難しくはないはずだ」と主張した。
CIOはうなずき、結果としては質問に答えることはできた。
残念ながら、プロジェクトの移行作業にはボーイング787ドリームモデル並みの労力が必要であった。

from Architecture Hard Parts 訳

このような質問でも、コンポーネントの依存関係判断パターンを適用することで答えることができる。

コンポーネントの依存関係とは

今回のプロジェクトのゴールは次の様な依存関係のグラフを表示することである。

from https://www.feststelltaste.de/java-type-dependency-analysis/

注意するべきは、このコンポーネントは、名前空間であってクラス名ではないということである。クラス名同士の依存関係ではなく、コンポーネントの依存関係に今回は着目する。

コンポーネントの依存関係は、あるコンポーネント（名前空間）のクラスが、別のコンポーネント（名前空間）の裏すと相互作用で発生する関係のことである。

この様な関係を可視化する補助ツールは多数存在するし、IDE自体にもコードベース内部のコンポーネントや名前空間の依存関係図を作成する機能を拡張するプラグインが存在する。

コンポーネントが分離されている場合

例えば、コンポーネント同士の関係が次ような状態であった場合。

このケースではアーキテクトは次の様に判断するだろう。

既存のモノシリックシステムは分解可能か？:はい
移行にかかる労力:少ない
コードの書き直しは必要か？:リファクタリングで良い

コンポーネント同士が結合されている場合

ほとんどのビジネスアプリケーションは次の様な状態のはずだ。

このケースではアーキテクトは次の様に判断するだろう。

既存のモノシリックシステムは分解可能か？:多分...
移行にかかる労力:通常の労力がかかる
コードの書き直しは必要か？:リファクタリングと書き直し両方が必要になる

コンポーネント同士が密着に結合されている場合

次の様に、コンポーネント同士が密着に結合されている場合

アーキテクトはこの会社またはこのプロジェクトからすぐに逃げ出すべきだ。

リファクタリングではノードグラフは重要

コンポーネント同士のこうした図表は、リファクタリングの際の妨げになりうる要素を探す探知機となり得る。 コンポーネントの結合度は、モノシリックなアーキテクチャの移行作業の実現可能性を決定する重要な要因だ

また、実際に結合が密集しているコンポーネントを発見した際には、そのコンポーネントを二つに分離するか、またはライブラリー(PythonのPyPIなど)として分離する選択肢がある。例えば、コンポーネントAへの入力の数が20だったとする。このコンポーネントを別の二つのコンポーネントへ分離することで、コンポーネントA1の結合度を14,コンポーネントA2の結合度を6の二つに分離することができる。

コンポーネントの結合度の監視

リファクタリングを行った後、望まない結合を防ぐためにはCI/CDパイプラインに適応度関数を追加する他ない。

次のコードは、Javaで動くArchUnitを使用した「望まない結合」を防ぐ適応度関数である。

public void ticket_maintenance_cannot_access_expert_profile() {
    noClasses().that()
        .resideInAPackage("..ss.ticket.maintenance..")
        .should().accessClassesThat()
        .resideInAPackage("..ss.expert.profile..")
        .check(myClasses);
}

from https://dl.ebooksworld.ir/books/Software.Architecture.The.Hard.Parts.Neal.Ford.OReilly.9781492086895.EBooksWorld.ir.pdf