🎃

アーキテクチャって...使ってたが、なんなんだ?を解消する

2023/05/06に公開

今まで、MVCアーキテクチャについてなども記事にしてきたが、
そもそもの話、アーキテクチャってなんだ?
なんのために存在するんだ?結局なんなんだ..?という疑問を晴らしていく。

アーキテクチャについて

直訳
architecture: 建築術や建築学、建築様式、建物、構造、構成

  • 直訳の通り、構造、構成などの言葉で置き換えられる、基本設計や設計思想という物だ。
    ( "○○アーキテクチャ"と出てきたら、"○○構造"と読み替えてみていいと思う。)

  • ソフトウェアシステムは、多数のコンポーネントや機能が組み合わさって構成されるため、
    複雑であると同時に、多様な要件を満たす必要がある。

    そのため、システム全体を設計するための枠組みが必要となります。それがアーキテクチャ!!!!!

  • ゆえに、ソフトウェアシステムを設計する上で必要不可欠な要素であり、
    システムの品質や保守性、拡張性、セキュリティ性を向上させるための重要な役割を果たす。

それぞれのプログラミング言語やフレームワークには、一般的に推奨されるアーキテクチャや設計原則がある

言語やフレームワークによってアーキテクチャの選択肢や推奨されるアーキテクチャが異なる場合がある。

■ Java言語
一般的に3層アーキテクチャMVCアーキテクチャが推奨されている。
これは、ビジネスロジック、データアクセス、プレゼンテーションの各層を分離し、
それぞれの役割を明確にすることで、保守性や拡張性を高めるための設計原則。

■ Ruby on Railsフレームワーク
MVCアーキテクチャが組み込まれており、
Webアプリケーションを構築する上で推奨される設計原則として位置づけられている。

■ Reactフレームワーク
コンポーネントアーキテクチャが推奨されている。
これは、UIを小さな再利用可能な部品に分割し、各コンポーネントの役割を明確にすることで、
メンテナンス性や可読性の向上を図るための設計原則。

以上のように、
言語やフレームワークによってアーキテクチャの選択肢や推奨されるアーキテクチャが異なる場合があるが、一般的には、保守性や拡張性を高めるために、分離や分割といった設計原則が共通して存在している。

アーキテクチャはなぜあるのか?

  • 一番上の項目でも説明したが、

アーキテクチャは、システムを構成する各要素や
コンポーネントの構造や役割、相互関係、インタフェースなどを定義する設計原則の集合体
だ。

システムの変更や拡張、保守を容易にするための設計原則を提供している。
アーキテクチャに基づいた設計に従ってコードを書くことで、
新しい機能の追加や既存の機能の変更が容易になる。

これにより、システムの保守性や拡張性を高めることができる。

アーキテクチャに従って、ソフトウェアシステムを構成する各要素を設計することで、
システムの品質、保守性、拡張性、セキュリティ性などを向上させることができる。

アーキテクチャを理解して、コードを書くことによるメリット

1. ソフトウェアシステムの全体像を把握できる:
アーキテクチャを理解することで、
システムの機能やコンポーネントの関係性、データフローなどを理解しやすくなる。
これにより、システム全体の設計や機能の改善点を把握することができる。

2. コードの保守性が向上する:
アーキテクチャを意識してコードを書くことで、コードの保守性が向上します。
アーキテクチャに基づいた設計に従ってコードを書くことで、コードの構造が明確になり、
変更や修正が容易になる。

3. 拡張性が向上する:
アーキテクチャを意識してコードを書くことで、システムの拡張性が向上します。
アーキテクチャに基づいた設計に従ってコードを書くことで、
新しい機能の追加や既存の機能の変更が容易になる。

4. ソフトウェアの品質が向上する:
アーキテクチャを意識してコードを書くことで、ソフトウェアの品質が向上します。
アーキテクチャに基づいた設計に従ってコードを書くことで、システムの安定性やスケーラビリティ、
セキュリティなどが向上する。

5. チーム内のコミュニケーションが円滑になる:
アーキテクチャを理解してコードを書くことで、チーム内のコミュニケーションが円滑になる。
アーキテクチャに基づいた設計に従ってコードを書くことで、
チーム内のコードレビューやデバッグ、コードの統合などがスムーズに進む。

モダンなフレームワークと保守性はイコールにならない

アーキテクチャの考え方

ここでいう「考え方」とは、
アーキテクチャを設計する上で重要とされる一連の思考プロセスや原則のことを指す。

アーキテクチャの考え方は、大きく以下のようなものがある。

1. 分割統治の原則:
大きな問題を小さな問題に分割し、それぞれの問題に対して適切な解決策を見つけることが重要。
アーキテクチャにおいても、システムを構成するコンポーネントを小さなモジュールに分割し、
それぞれのモジュールが単一の目的を持ち、疎結合であることが望ましい。

2. 抽象化の原則:
アーキテクチャは、コンポーネントやモジュールの実装の詳細に依存せず、
高いレベルでの抽象化に基づいて設計することが重要
。これにより、システムが拡張性が高く、変更に強くなる。

3. 設計原則の適用:
アーキテクチャの設計には、一般的に一連の設計原則が適用される。
これらの原則は、設計の品質を高め、システムの保守性、拡張性、可用性、効率性などの性質を改善する。
代表的な設計原則には、
DRY(Don't Repeat Yourself)、KISS(Keep It Simple, Stupid)、
YAGNI(You Ain't Gonna Need It)、SOLIDなどがある。

4. パターンの利用:
アーキテクチャの設計には、一般的に一連のデザインパターンが利用される。
これらのパターンは、設計上の問題を解決するための一般的なソリューションを提供するものであり、
再利用性が高く、品質の高い設計を可能にする。

5. モジュール化:
アーキテクチャにおいては、システムを独立したモジュールに分割することが望まれる。
モジュール化することで、システム全体の機能や責任を明確にすることができ、
変更や拡張に対してより柔軟
な対応が可能になる。


ここには経験が必要になってくると思うので、
もっと経験を積む中で意識して学んでいきたいと思う。

Discussion