4章アーキテクチャ特性
問題をソフトウェアで解決しようと決めた企業は、システムに必要な要件を収集する。要件の収集には、さまざまな手法が存在している。そして、それらは通常、チームが採用しているソフトウェア開発プロセスによって定義される。しかし、図4-1に示すように、アーキテクトは、ソフトウェアを設計する際に他にも多くの要素を考慮する必要がある。
アーキテクトは、ドメインやビジネスの要件を定義することに協力しつつも、重要な責務を1つ持つ。それは、ドメインの機能には直接関連しないがソフトウェアが満たさなければならないすべてのこと、すなわちアーキテクチャ特性を定義、発見、分析することだ。
コーディングや設計とアーキテクティングの違いは多岐にわたる。その1つには、アーキテクチャ特性を定義するというアーキテクトの役割がある。アーキテクチャ特性とは、問題領域とは独立した、システムの重要な側面だ。ソフトウェアのそうした特徴を非機能要件と呼ぶ組織も多い。しかし、非機能要件という用語は否定表現だ。そのため、著者らはその表現を好まない。非機能要件という用語は、アーキテクチャ特性を機能要件と区別するために作られたものだが、その名前から、何処となくネガティブな印象を生じさせてしまうと、著者らは考えている。では、どんな用語であれば、「機能ではない」ものに注意を十分払うようにできるだろうか。よく使われる別の用語に、 ...
Get ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.