技術的な結合度と設計的な結合度

ささっとBlogを書く訓練。

エンタープライズシステムではシステム間を疎結合に保つことが重要とされます。結合度が下がっていれば両者の依存関係は弱くなります。システムAとBがあったとして、Aが停止した場合に、それによってBが停止しない（縮退はするかも）、あるいはAの内部仕様に変更があった場合に、それによってBが仕様変更を強制されることがない、という示しています。

結合度が低ければシステムのライフサイクルをずらすことができるため、運用上も保守上も大きなメリットになります。

とはいえ、結合度が高いことでのメリットもあります。主にはコストの低下や性能の向上が見込めます。

マスタデータを共有したい場合、ファイルによるデータ交換は結合度を下げることができます。ですが、双方がファイルを入出力する仕組みを作る必要があり、かつ、連携遅延が出てしまいます。そうではなくて、直接データベースを共有するようにすればコストも掛からず、連携遅延も発生しません。

ただし、データベースが停止すれば両システムとも停止するでしょう。また、片方のシステムの都合でテーブル設計が変わった場合、もう片方のシステムは引きずられてテストをしたり、リリースをする必要が出てきます。

マスターデータの共有に「ファイル連携」をすべきか、「共有データベース」にすべきかというのは結合度の調整であり、どちらかが良いわけではありません。ケースバイケースで最適な手法を選択すれば良いです。

と、ここまで書いたのが技術的な観点での結合度になります。

もう1つ設計的な観点での結合度も考える必要があります。設計的な結合度というのは、設計のズレのことを指します。

設計的な結合度が低い状態というのは連携時に変換が少ないことを示します。逆に結合度が高いというのは変換が多く、そのための処理が実行されていることを示します。

ですから技術的な観点では結合度が低い場合でも、設計的な観点では結合度が高くなる可能性があります。たとえばファイル連携はしているものの、その間の変換処理が大量にある場合です。

逆に技術的な観点で結合度が高いが、設計的な結合度が低いこともあります。共有データベースでテーブル設計が共有できている状態ですね。基本的に結合度を上げるためには、設計的な結合度を下げる必要があると言えます。

もちろんデータベースの機能でビューを使うなど、設計的な結合度が低くても、技術的な結合度を上げる手法は存在します。ですが、こういった機能は障害が発生しやすいため基本的には避けるべきです。

この設計的な結合度についてはシステム間連携が少ないうちは大きな問題にはなりません。しかし、システム間連携が増えるほどにコストや性能の問題が出てくることになります。

エンジニアは技術的な結合度の話が大好きです。ですが、現実的にシステムを運用保守する上では設計的な結合度に注意を払う必要があります。

設計的な結合度をきちんと管理するためには連携先システムの業務仕様に踏み込んで理解する必要があり、それはつまり、全社的な視点から最適化を考える必要があるということになります。

単一システムをいかに作るか、というだけではなく周辺システム、ひいては全システムを視野に入れた発想をしていくことが大事と言えるでしょう。