ソフトウェアアーキテクチャの重要性

ソフトウェアアーキテクチャはビジネス成功において重要です。不確実性の高いソフトウェア開発の現場において、優れたアーキテクチャは変更容易性を高め、ビジネスを頑強なものにします。

1. コスト削減と効率向上
   1. 優れたソフトウェアアーキテクチャは、開発プロセスの効率化を促進し、長期的なコスト削減に貢献します。再利用可能なコードやモジュール設計により、新機能の追加や変更が迅速かつ低コストで実施可能となり、開発チームの生産性が向上します。
2. スケーラビリティと拡張性
   1. 成長を見据えたビジネスには、将来的な負荷増大や機能追加に対応できるスケーラブルなソフトウェアが必要です。しっかりと設計されたアーキテクチャは、システムがビジネスの拡大に合わせて柔軟に対応できる基盤を提供します。
3. リスク管理と信頼性の向上
   1. 堅牢なアーキテクチャ設計は、システムの信頼性と安定性を高めます。冗長性やフォールトトレランスを組み込むことで、障害発生時の影響を最小限に抑え、ビジネス継続性を確保します。これにより、ダウンタイムによる損失を防ぎ、顧客の信頼を維持します。
4. 迅速な市場投入と競争力強化
   1. 市場の変化に迅速に対応できるアジリティは、競争力の源泉です。柔軟なアーキテクチャは、新しいビジネス要件や市場のトレンドに素早く対応するための迅速なプロトタイピングとリリースを可能にし、競争優位性を確保します。
5. セキュリティとコンプライアンス
   1. 情報セキュリティの重要性が増す中、セキュアなアーキテクチャはビジネスの信頼を支える柱です。セキュリティ要件や法規制に対応した設計は、データ保護やプライバシーの確保を実現し、法的リスクを軽減します。

クリーンアーキテクチャ

弊社ではソフトウェアアーキテクチャにクリーンアーキテクチャの考えを採用しています。

クリーンアーキテクチャはRobert C. Martin(Uncle Bob)（ボブおじさん）が提唱したアーキテクチャです。クリーンアーキテクチャは依存性のルールとSOLID原則を守ることが重要です。

依存性のルール

ソースコードの依存性は、内側（上位レベルの方針）だけに向かっていなければいけない。

Clean Architecture 達人に学ぶソフトウェア P201

SOLID原則

• 単一責任の原則 (Single-Responsibility Principle; SRP)

  変更するための理由が、1つのクラスに対して1つ以上あってはならない

• 開放閉鎖の原則（Open/Closed Principle; OCP）

  ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開かれているべきであり、修正に対して閉じていなければならない）

• リスコフの置換原則（Liskov Substitution Principle; LSP）

  ある基底クラスへのポインタないし参照を扱っている関数群は、その派生クラスのオブジェクトの詳細を知らなくても扱えるようにしなければならない

• インターフェース分離の原則 (Interface Segregation Principle)

  汎用なインターフェースが1つあるよりも、各クライアントに特化したインターフェースが、たくさんあった方がよい

• 依存性逆転の原則（Dependency Inversion Principle; DIP）

  上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも具象ではなく、抽象（インターフェースなど）に依存するべき

一例に過ぎない

書籍には以下のように書かれており、弊社では、よく目にする図のとおりではなく参考程度にして開発をしています。

図22-1の円は、概要を示したものである。

したがって、この4つ以外にも必要なものはあるだろう。この4つ以外は認めないというルールはない。

ただし、依存性のルールは常に適用される。

Clean Architecture 達人に学ぶソフトウェア P202

弊社の構成

レイヤーの数は3つ

境界を作るコストと、アーキテクチャの複雑さを考慮し、Frameworks&Driversは撤廃し、3つの層に分けています。

• adapter 外部サービス・フレームワークなどの詳細部分
• useCase アプリケーション固有のビジネスルール
• domain 最重要ビジネスルールと最重要ビジネスデータ

専門用語の説明を記載しておきます。

• ビジネスルール

  システムが自動化されていなくても存在する、ルールや手続き。

• ビジネスデータ

  システムが自動化されていなくても存在する、ビジネスルールで必要となるデータ。

• アプリケーション固有のビジネスルール

  自動化されたシステムを使用する方法を記述したもの。

ディレクトリ

一般的なREST APIでのディレクトリ構成は以下のようにしています。

├── adapter  # 詳細
│   ├── db  # データベース
│   └── handler  # HTTPの処理のハンドラ
├── useCase  # ユースケース・ビジネスロジック
│   ├── interactor  # ビジネスロジック
│   ├── outputPort  # adapter層のインターフェース
│   └── inputPort  # interactorのインターフェース
├── domain  # ドメイン
│   ├── entity  # DDDにおけるエンティティ
│   └── valueObject  # DDDにおける値オブジェクト
└── main  # 依存性の注入をする

依存性を図示すると以下のようになります。

inputPortについて

outputPortが依存性逆転のために必要なことは有名です。

しかしinputPortについてはどうでしょうか。

書籍によると以下の記述があり、層の外側が層の内側の実装に対し推移的に依存することを防ぐことが目的のようです。

FinancialReportRequesterインターフェイスは、依存関係の逆転とは別の役割を担っている。このインターフェイスの役割は、FinancialReportControllerがInteractorの内部を知りすぎないように保護することである。このインターフェイスがなければ、Controllerは推移的にFinancialEntitiesに依存してしまう。

Clean Architecture 達人に学ぶソフトウェア P91

さいごに

本記事では、クリーンアーキテクチャの概要や、Webでの説明があまりない部分の説明をおこないました。

また、弊社での実装事例を紹介しました。

単にディレクトリ構成を真似てみるのではなく、自社の体制や方針に応じて設計を検討することが重要です。

守るべきは「ソースコードの依存性は、内側（上位レベルの方針）だけに向かっていなければいけない。」これだけです。

ソースコードは存在するだけで負債です。ソフトウェアが複雑化する現代において、その負債を少しでも小さくするために、メンテナンス性、拡張性、テスト容易性を高めることが大切です。