BSA / Principles First, Second, and Third

第一原則、第二原則、第三原則 †

要約 †

アーキテクチャを作って、成熟させて、育てて、維持していく作業は、アーキテクトと開発者による設計時の選択に左右される。 選択によっては、アーキテクチャが根本的に変わってしまうので、さまざまな案を評価してよりよい案を見つけられるようにする必要がある。 ここでは、アーキテクチャの設計に関する原則をまとめる。

カプセル化 †

アーキテクチャをセパレートに構成し、独立性を保っておく。そして、内部的な実装は、お互いに見えないようにする。

例：電話料金請求システム

インターフェイス †

大規模設計におけるサブシステムどうしのやりとりを、明確に定義する。 その方法のひとつが、具体的な実装を抽象化すること。 抽象をプログラミングすることで、実装の変更が必要になっても対応しやすくなる。

例：ファイルへの出力をするプログラム

例：ODBC

疎結合性 †

結合性とは、システム内の異なるパーツの間の接続の度合い。これを疎にしておいたほうが、理解しやすいしテストもしやすい。再利用も保守も楽。 最初の二つの原則に従っていれば、疎結合にしやすくなる。

適切な粒度 †

粒度とは、ひとつのコンポーネントにどの程度の作業をさせるのかということ。 あまりにも粒度を細かくしすぎると、それらを組み合わせたソリューションを作りづらくなる。何かの作業をするために必要なつぎはぎの量が多くなりすぎてだな……。

高凝集性 †

凝集性とは、コンポーネント内のアクティビティがどれほど密接に関連しているか…みたいなこと。 凝集性を高めて、各コンポーネントがそれぞれひとつのタスクだけに専念するようにする。

パラメータ化 †

コンポーネントをカプセル化しても、何らかのパラメータ化をしなければ作業はできない。 洗練されたパラメータ化の形式のひとつがIoC。これは、フレームワークの内部やプラグインアーキテクチャで見受けられる。 あるコンポーネントが、処理の制御を別のコンポーネントに手渡す。

先送り †

確証のないままでの決断を迫られることが多い。 「何らかの機能を実行するためのライブラリを選ぼうとしているが、どのベンダーが最高のパフォーマンスを提供してくれるのかがわからない」 「マネジメントチームが、複数の業者と交渉して、よい条件での契約を求めている」 など。

こういった決断を可能な限り先送りすることで、チーム全体として最良の選択をできる可能性が高まる。

担当者のつぶやき †

みんなの突っ込み †