アプリケーション開発の現場では長らく「疎結合」がトレンドです。
わたしが疎結合を取り入れた開発プロジェクトに参画したのは2000年です。
オブジェクト指向設計をしたアパレルメーカーの生産管理システムの開発プロジェクトです。
アパレルのサプライチェーンは下記の流れです。アパレルメーカーは製造工程の一部を外部に委託することが多く、生産管理システムは、製造工程の進捗状況を把握する機能が求められました。
生産管理システムには、委託先への発注や生産指図、進捗状況の登録と、参照機能を組み込みました。専用のWebアプリケーションを通じて、製造のコラボレーションをする仕組みを開発しました。
「疎結合」を意識したのは、ITのトレンドに乗っかる意味合いもありました。
でも、それだけが理由ではありません。
アパレルメーカーを支える基幹システムは、生産以外にも、商品を小売店に配分する仕組みや、マーチャンダイザーを支援する仕組みなども必要でした。
アパレルメーカーのシステム構築にあたっては、オブジェクト指向を取り入れることで、他システムの稼働状況に左右されない仕組みとしたかったのです。
「疎結合」とは、その名のとおり、お互い依存していない関係を指します。
「疎結合」を親子３人家族でたとえるなら、家族は同じ家に住んでますが、個々にスケジュールを立てて、自分のペースで行動するイメージです。
妻も夫も独立して通勤します。子どもは親に依存することなく、自律的に行動します。朝食や夕食も家族みんなで無理して、時間をあわせることはありません。チャットをつかって、帰宅時間は共有しても、食事は各自が適当なタイミングでとるライフスタイルです。
それまでのわたしは、ERPパッケージ導入に代表される「密結合」のプロジェクトへの参画がメインでした。
はじめての疎結合の仕組みに大いなる期待をもって、プロジェクトに参画しました。
しかし、稼働間際に大きなトラブルになったのが強烈な印象として残ってます。
パフォーマンス問題です。
疎結合のシステムは、各コンポーネントが独立しているため、通信や同期処理が必要です。この処理がパフォーマンスに悪影響を及ぼしたのです。
１件のデータ処理は、大きな遅延を感じなくとも、データが大量になると「塵も積もれば山となる」のです。
システムの利用者を集めた操作研修で、問題が露呈しました。
研修に参加した何十名もの社員が一斉にシステムにデータ登録した時点で、画面が応答しなくなったのです。
パフォーマンスの悪さはシステムの可用性を損ないます。
設計思想は良くても、そんなシステムは、実務で使えません。
原因調査すると、システム操作に対して、SQLクエリが大量に発生してました。
この処理が遅延し、操作画面をブロックしていたのです。
疎結合のシステムでは、各コンポーネントがデータを独立して取得しようとします。そのため、同じデータベースに対して複数回クエリを実行することになります。リレーショナルデータの取得において、最初のクエリで多数のレコードを取得し、各レコードに対して追加のクエリを実行する「n+1問題」が発生してました。
- 最初のクエリ（1回目）：主テーブルからn個のレコードを取得する。
- 次のn回のクエリ：各レコードに関連するデータを取得するために、関連テーブルに対してn回の個別のクエリが実行される。
結局、最初のクエリで関連データをまとめて取得するような改修を行い、リリースの運びとなりました。
稼働は3ヵ月遅れました。
疎結合は長らく、システム開発のトレンドになってます。ただ、決して密結合よりも優れているわけではないことがこの例から分かります。
トレンドである疎結合の良さと、密結合は強みが相反します。
システムに求めるべく要件によって柔軟に選択するべきでしょう。
疎結合が有効なシステム
- 大規模なシステム：大規模なシステムは、柔軟性とスケーラビリティが重要となるため、疎結合が適してます。
- 頻繁に変更が必要なシステム：変更がちょくちょく発生するシステムは、変更の影響を局所化できる疎結合が適してます。
密結合が有効なシステム
- 高速な処理が求められるシステム：パフォーマンスを要求されるシステムは、密結合の方が適してます。
- データの一貫性が重要なシステム：データの一貫性が重要な場合、密結合が適してます。
家族でも同じですね。
どういうライフスタイルを求めるか！？
夫婦子どもの自律的な行動を促す疎結合な家族と、サザエさん一家のようにいつも家族が団らんして食卓を囲む密結合な家族。
