ソフトウェアアーキテクチャ

作成日時：2024-08-01以前
更新日時：2025-07-22

アーキテクチャ

• 様々な物に触れる
• ドメイン知識

ソフトウェアアーキテクチャの基礎

ソフトウェアアーキテクチャの第一法則
ソフトウェアアーキテクチャはトレードオフがすべてだ。

ソフトウェアアーキテクチャの第二法則
「どうやって」よりも「なぜ」の方がずっと重要だ。

Mark Richards, Neal Ford. ソフトウェアアーキテクチャの基礎: エンジニアリングに基づく体系的アプローチ. 島田 浩二訳. 19-20.

【WIP】アーキテクチャ特性

品質特性。

P.60

アーキテクチャスタイルスタイル

アーキテクチャの一覧。
アーキテクチャはそれぞれ組み合わせることができる。

• レイヤードアーキテクチャ
  • MVC
  • Spring Boot
    • モジュラモノリスなSpringもある
    • Spring Modulithで始めるモジュラモノリス開発 - Speaker Deck
• パイプラインアーキテクチャ
  • Apache Kafka
• マイクロカーネルアーキテクチャ
  • Eclipse、決済
• サービスベースアーキテクチャ
  • モノリスとマイクロの中間
  • サービスごとの分離。マイクロよりは緩い分割。
  • DBは1つ、またはサービス単位なので、トランザクション管理が容易。
    • DB間の整合性を気にしなくてもよい(DBを跨がないならば)
  • 「管理者サイトとユーザサイトで分けた」というのは分散モノリスっぽい
• イベント駆動アーキテクチャ
  • MQ
  • ブローカートポロジーとメディエータートポロジーがある。
    • 前者は処理の順番を制御できない、後者は出来るが速度が下がる
• スペースベースアーキテクチャ
  • 高負荷環境
  • 処理ユニットでデータキャッシュを共有し、DBにはキューか何かで非同期で更新、取得。
• サービス指向アーキテクチャ
  • ESB、SOA
• マイクロサービスアーキテクチャ
  • 細かい分割。各サービスがDBを持つ。
  • コレオグラフィ/オーケストレーション
  • サイドカーコンテナー
    • サービスメッシュにおいて、メインコンテナーのプロキシとなる。
    • ロギングやメトリクス収集、SSL終端などを代わりに行い、メインの負荷を軽減。
    • 別Podに転送したり。
    • 参考：Software Design 2024年7月号 連載「レガシーシステム攻略のプロセス」第3回 API Gatewayとサービスメッシュによるリクエスト制御 - ZOZO TECH BLOG
    • 参考：istio

simple is bestなので、レイヤードでいい。
それ以外は、レイヤードでは解決できない問題がある/起こりうる場合になってから考える。
データストアでいきなりNoSQLを選択しないが如く。

分散系のアーキテクチャは、レイテンシがあるし、トランザクション管理が面倒くさい。
クラウドの場合、サービス間の通信に対してコストが掛かる。

参考：DMMはAWS“から”オンプレミス“に”切り替える　サーバーとネットワークのコストから見直す適切な環境選び | ログミーBusiness

• デプロイ容易性
• そのサービスに適した技術で実装できる
  • 一枚岩だと他サービスの内容が、技術選定に影響を与える。
• 作業分担できる

変更しやすい体制を

考えたアーキテクチャが正解である保障は無いし、そもそも正解はない。
だからこそ変更しやすい体制が無ければならない。
ADR、自動テスト、ドキュメント、キレイなソースは必須。
これらは変更する勇気を与える。

キューによる疎結合

モジュラモノリス

• 単一のデプロイ単位
• 内部的なモジュール性
• 単一プロセスでの実行

サービスごとにjarを作成し、それらをまとめてwarにしている場合はモジュラモノリスと言える。

1サーバーに複数コンテナーを建て、それらを協調させて1つのアプリにするのは、
厳密にはモジュラモノリスでは無いが、それの精神性を持っている。

早期リターン

ガード節と同じ。
リクエストを受け取ったらすぐレスポンスを返し、裏で処理を実行する。
非同期。

キューってDBでも出来るよね

定期的にポーリングする感じで。

サーガ(Saga)パターン

分散環境におけるトランザクション管理。
処理に失敗した際、関連する更新を戻す。(補償トランザクション)
下記の2パターン。

• 仮登録⇒本登録
• 本登録⇒取消登録

ADR

書け。
「何故」が分からなければ正当な実装は出来ない。
アーキテクチャの変更の妥当性も検証できない。

書くことによって、思考を整理できる。

AI

文書として残せば、MCP経由でAIに読み込ませて質問できる。
また、エージェント系のAIにコーディングしてもらう際も、
ADRはその成果物の品質を上げることに役立つ。

弾力性(だんりょくせい)

スパイクアクセスに耐えられる力。

ドメインの理解

• キーパーソン
• ヒアリング
• アンケート

アーキテクトの流れ

1. 方針
2. 現状分析
3. 問題点分析
4. 解決策決定
   • 全部システム化する必要はない
   • 運用で回避でもいい
5. システム化対象の決定
6. 機能要件/非機能要件/データ洗い出し

優先順位の概念

アナロジー思考

分散系は「小さくする」事で、変更容易性やデプロイ容易性を得た。
これはコーディングでも同じ。SOLIDやDDDとかも。
ある考え方は他の領域にも使える。

クリーンアーキテクチャ

DB操作は外側のrepositoryで行われる。
内部のdomainがrepositoryを使用するならば、依存性が外側に向かっているのでは。
↓
否。
domain層にrepositoryのinterfaceがある。
repositoryはそのinterfaceに依存するから、依存性の方向は内側に向かっていて正しい。

レイヤードはこの順で依存か

プレゼンテーション層
アプリケーション層
ドメイン層
インフラストラクチャー層

フィーチャフラグ

トランクベース開発などで、ブランチの複雑性の解消やビックバンリリースの回避をしたりするときに使う。
開発が終わっていないものをリリースできたりする。

フィーチャートグル

複数のソースコードのブランチ（機能ブランチ）を維持するのとは別の方法を提供しようとする手法

• 新機能の段階的なロールアウト
• A/Bテスト
• 実験的な機能の制御
• 特定の環境や状況での機能の有効/無効の切り替え

フィーチャーフラグとアクセス制御

権限やデプロイ先に応じて処理の有効無効を切り替えるのは、フィーチャーフラグではない。
ただの機能制御。

外部アクセスは遅くなる

• 過剰なマイクロサービスはオーバーヘッドが大きい
• DB：やり取り/データ量を小さくすべき
• WEB<=>APもオーバーヘッド

多少おそくなってもやりたいことがあるならば、それをすべき。
クラウドならコストかかりそうだけど。

複数台サーバー

スティッキーセッションかredisまたはdb。

FURPS+

Webアプリケーション開発者から見た、MVCとMVP、そしてMVVMの違い #MVVM - Qiita

MVC(原初のMVC)
U -> C -> M -> V -> U。

MVC(Model2MVC=webのMVC。WEB向け)
U -> C -> M -> C -> V -> U。

MVP
U -> V -> P -> M -> P -> V -> U

原初のMVCとMVPを比べれば違いが分かった
ModelとViewを疎結合にしている。

Cが忙しいからファットコントローラーになる。

MVPとMVVMの違いは、
MVPはViewがPresenterに処理を委譲している。
MVVMはViewがViewModelを介してデータを取得している。データバインディング。

Claudeに聞いたMVC / MVP / MVVM

Model2MVC、MVP、MVVMは、ソフトウェアアーキテクチャの異なるパターンです。
それぞれが、モデル（データ）、ビュー（UI）、およびコントローラー（アプリケーションの振る舞い）の間の役割と責任を異なる方法で分配します。
以下にそれぞれのアーキテクチャの要点を示します。

Model2MVC（Model2 Model-View-Controller）

Model2MVCは、従来のMVC（Model-View-Controller）のウェブアプリケーションでの使用を拡張したものです。
クライアントとサーバーの間でモデル、ビュー、およびコントローラーの役割が分離されます。
サーバーサイドでは、コントローラーがリクエストを処理し、ビジネスロジックを実行し、モデルを更新します。
クライアントサイドでは、ビューが生成され、ユーザーインターフェイスを表します。

MVP（Model-View-Presenter）

MVPは、ビューとモデルの間にプレゼンターがあり、ビューはユーザーインターフェイスを表示し、
プレゼンターはビジネスロジックを含むコントローラーの役割を果たします。
プレゼンターは、ビューとモデルの間の仲介者であり、ビューからのユーザーアクションを処理し、
必要に応じてモデルを更新してビューに反映します。

MVVM（Model-View-ViewModel）

MVVMは、ビューモデルがビューとモデルの間の仲介者となるアーキテクチャです。
ビューモデルはビジネスロジックを含み、ビューからのユーザーアクションを処理し、モデルの状態をビューにバインドします。
ビューは、ビューモデルの状態に応じて自動的に更新されます。
それぞれのアーキテクチャには、異なるメリットとデメリットがあります。プロジェクトの要件や特性に応じて、
適切なアーキテクチャを選択することが重要です。