は、プログラム（ソフトウェア システム）の主要な動作および構造的特性を決定する設計上の決定を明確にするものです。 戦略的な決定は、グローバルでシステム全体の懸念に対処し、最も重大な影響を及ぼします。 戦略的決定には、プログラミングパラダイム（「オブジェクト指向プログラミング」）、アーキテクチャスタイル（「パイプとフィルター」）、アプリケーションフレームワーク（「Microsoft Foundation Classes」）、コンポーネントベースのソフトウェアエンジニアリング標準（「Enterprise JavaBeans」）、および設計原則（「普遍的ベースクラス」）の選択、ならびにアーキテクチャの不一致（「ソフトベンチ放送メッセージサーバーは、すべてのコンポーネントにグラフィックユーザーインターフェイスがあることを期待した」）や法則性に基づく規則（「システム内のすべてのクラスはクラスCから継承される」）につながりうる前提が含まれる。 戦略的決定は、それがもたらす結果のため、ソフトウェア開発プロセスの初期に行われる必要があり、詳細設計が行われる前に明示的に確立されるべきである
対照的に、戦術的設計文は、特定のモジュールに関係する設計決定を明示する。 戦術的決定はしばしば、モジュール（オブジェクト、プロシージャ、クラスなど）の1つのコレクションと別のモジュールとの間の相関関係のパターンを記述する。 直感的に言えば、Tacticalステートメントは、そのスコープがプログラムの一部に限定され、その外側にはないという意味で「ローカル」である。 戦術的な決定には、デザイン パターン (‘Factory Method’) の選択、リファクタリング (‘Replace Conditional With Polymorphism’) 、およびプログラミング イディオム (‘Counted Pointer’) などがあり、通常、ソフトウェア開発プロセスにおいて戦略的設計決定よりもずっと後に行われます。
グローバル = 戦略、ローカル = 戦略という一般規則に大賛成ですが、絶対視するべきではありません。 システムの 1 つのセグメントがアーキテクチャ全体に強く影響する側面を持つことは可能です (Booch の重要性の基準を正当化するものです)。 これが、私が機能要件は設計で非機能はアーキテクチャであるという意見を持たない理由である。
Nice SystemsのアーキテクチャマネージャであるArnon Rotem-Gal-Ozは、プレゼンテーション「Software Architecture」でアーキテクチャのいくつかの側面を特定している。 アーキテクチャは、システムの主要な構成要素、それらの関係や相互作用で構成されています。 これらの主要な構成要素のデータと動作は、これらの構成要素間の相互作用の観点からしか、アーキテクチャに関係しません。 Booch氏と同様に、Rotem-Gal-Oz氏もアーキテクチャをシステムの中で最も変更しにくい部分であると特徴づけている。 Eden、Kazman、および Hirshfeld と同様に、彼はアーキテクチャをプロセスの最も早い段階で行わなければならない設計上の決定であると定義しています
戦略的で基盤となる設計決定の価値は明らかでしょう。 システムのこれらの側面は変更するのが困難でコストがかかるため、最適な選択をするためのインセンティブがかなりあるはずです。 Kevlin Henney が developerFusion の「ソフトウェア アーキテクチャとは何か」で述べているように、
問題は、システムがアーキテクチャを持っているかどうかではなく、そのアーキテクチャが優れているかどうかである。 意図的か偶然か、明示的か暗黙的か、良いか悪いかにかかわらず、すべてのシステムにはアーキテクチャがあります。
アーキテクチャを変更コストに関連づけたことで、アーキテクチャの品質を評価する簡単な方法を手に入れました。 良いアーキテクチャはシステムを安く作るのではなく、進化させるのも安くするのです。 言い換えれば、良いアーキテクチャとは、設計上の決定の重要性が最小化されたものである。 システムの多くの側面を自由に変更することができ、その変更が困難であったり、コストがかかったり、バグの連鎖が発生したりすることを心配する必要はありません。 したがって、良いアーキテクチャは持続可能なものです。
これらの設計上の決定の重要性を考えると、それを偶然に任せることはほとんど意味がないのです。 持続可能で柔軟な建築は、有機的に出現することはまずありません。 建築家の役割にある誰か（その役割がフルタイムかパートタイムかにかかわらず）が十分な計画と調整を行う必要があります。 8190>
時折、ビッグ デザイン/要件アップフロントに対するアジャイルのマントラをまだ持ち上げている人がいるのを耳にすることがあります。 アジャイルマニフェストは、システムの目的に関して意図的に砂に頭を埋めろとは言っていないということです。 それは、文書しか出てこないのに分析に何ヶ月も費やすことに対する反発であり、ゴールは中間点に到達することだったのです。 誰も「前もって設計するな」とか「前もって要求するな」とは言っていません。
（Udi Dahan、「A CQRS Journey – with and without Microsoft」より）
Reposted from Form Follows Function
.