ソフトウェア・アーキテクチャパターン

概要

ソフトウェア・アーキテクチャの勉強会に招待されたので改めて勉強しようと思い至りました。 最近だとクリーンアーキテクチャが話題ですが、 全体感を知るためにSoftware Architecture Patternsを読んでみたいと思います。ちゃんとした和訳を載せたりすると問題になるので自分の備忘メモを書きます。

詳細

Layer Architecture

ほとんどの人が最初に学ぶアーキテクチャだと思います。 上位から、Presentation, Business, Persistence, Databaseの層が基本となります。

観点 評価値 補足
Overall agility モノリシックな実装になりやすいため
Ease of deployment 大きなアプリになると小さな変更のためにアプリ全体をデプロイし直しが発生しやすい
Testability 別レイヤをモック化しやすい
Performance レイヤを何個もまたがる必要があるので非効率
Scalability モノリシックな実装になりやすいため
Ease of development 皆が知っており簡単なので

Event Driven Architecture

分散非同期でスケーラブルなシステムに適しています。 mediator と broker の2つのトポロジが出現します。 複雑な仕組みなので別途、実例を探して深堀りしたいと思います。 実装上は分散システムに必要な可用性の担保や、機能の一部がフェールした場合の対応が求められます。 実際にビジネス層の処理をする(event processorコンポーネント同士は独立性が高くなり、 トランザクション中に情報連携することは難しくなります。 またeventのデータフォーマットを最初から適切に決めておく事が大事です。

観点 評価値 補足
Overall agility event processor componentは独立性が高く単一目的の処理だけを行うため
Ease of deployment event processor componentは独立性が高いため
Testability 単体ユニットのテストはそれほど難しないが非同期にeventを発生させるのが厄介
Performance
Scalability event processor componentは独立性が高いため
Ease of development

Microkernel Architecture

プロダクトベースに開発する。コアシステムとプラグインから構成される。 OS系の本を読むと最初に紹介されるアーキテクチャですね。

観点 評価値 補足
Overall agility
Ease of deployment
Testability
Performance
Scalability
Ease of development

Microservices Architecture

デプロイ単位が分離されているため効率的に容易に継続的デプロイができます。 サービスコンポーネントの粒度を決める事は、最も難しい作業です。 主なトポロジは、API REST-Based、Application REST-Based、Centralized Messagingです。

観点 評価値 補足
Overall agility
Ease of deployment
Testability
Performance
Scalability
Ease of development

Space Based Architecture

CDNとかAWSのオートスケーリングの事を言っているような気がしましたが、 作る側として検討したことがないのでいまいち理解できませんでした。 一般的なWeb-Basedアプリにおいて、負荷が高くなると Webサーバ→Applicationサーバ→DBサーバとボトルネックが移行します。 後ろへ行くにつれてリソース追加が難しくなります。 そこでProcessing Unit(Applicationサーバ?)のメモリ上にデータを保持させて、 各Processing Unit同士で同期を取らせるようです。 負荷が増減に応じてProcessing Unitを追加・除去します。 かなり難しい処理が必要になりそうです。

観点 評価値 補足
Overall agility
Ease of deployment
Testability
Performance
Scalability
Ease of development