ソフトウェアアーキテクチャの基礎輪読会 10章
日付：2023/11/15
章：10
調査者：iNoma.icon
章のまとめ
どんな内容が書かれているか？
要約
レイヤードアーキテクチャのメリットとデメリット
メリット
シンプルさ、コストの低さ
デメリット
スケールのしづらさ
レイヤードアーキテクチャ
最も一般的なアーキテクチャの一つ
シンプルさ、親しみやすさ
組織にとって自然な形で開発できる
層ごとにチーム分け可能
takasshii.icon8章で出ましたわね
アンチパターンにも該当しうる
takasshii.icon:naruhodo
トポロジー
レイヤ内のコンポーネントは、レイヤに関連するロジックのみを扱う
メリット
層ごとに専門的な技術知識を活用し、技術的な側面だけに集中できる
デメリット
takasshii.iconそうなんだ！
基本的なレイヤードアーキテクチャは以下の4層（標準レイヤー）からなる ビジネス層に統合されることも
デプロイの観点からさまざまなバリエーション
バリエーション１
プレゼンテーション層、ビジネス層、永続化層を統合してデプロイ
データベースは外部に物理的に独立
バリエーション２
プレゼンテーション層を物理的に独立
ビジネス層、永続化層を統合デプロイ
データベースは外部に物理的に独立
takasshii.iconUseCaseは自由にしてください〜のUseCase無いversionかな
バリエーション3
4つの標準レイヤー全てを統合
内部的に埋め込まれたDBやインメモリDBを使う小規模アプリに最適
外部通信しないタイプのモバイルアプリはこれかなiNoma.icon
takasshii.icon:tasikani
ichimura.icon naruhodo
層の分離
あるレイヤーの変更が他のレイヤーに影響を与えない、という考え方
各層は以下のどちらかである
閉鎖レイヤー
層のスキップを禁止する
層の分離をサポート
開放レイヤー
層のスキップを容認する
簡単で、(開発、あるいは実行速度が)高速
層の分離が困難
開放レイヤーが層の分離を破壊する例
プレゼンテーション層とビジネス層の両方から永続化層にアクセスできる場合
永続化層の変更がプレゼンテーション層とビジネス層の両方に影響
密結合で脆いアーキテクチャへ
クイズ
この例で、開放レイヤーとなっているのはどれでしょう？iNoma.icon
ビジネス層をスキップしているので、開放レイヤーになっているのはビジネス層
レイヤーの追加
4つの標準レイヤ―から拡張する１例について述べる
書籍の図10-4を参照(p141)
ビジネス層の中で、様々なコンポーネントがアクセスできる共通コンポーネントを考える
例
日付や文字列のユーティリティなど
共通コンポーネントには、ビジネス層のコンポーネントからのみアクセス可能で、上位レイヤーからはアクセス不可としたい
この場合、ドメイン層の下層に共通コンポーネントのための開放レイヤーをつくるとよい
ここでは「サービス層」と呼ぶ
書籍の図10-5を参照(p142)
takasshii.icon👀
サービス層は開放レイヤーであるためスキップ可能
ビジネス層は、サービス層にアクセスするか、永続化層にアクセスするかを選択できるようになる
その他の考慮事項
別のアーキテクチャへの移行が容易なアーキテクチャでもある
移行を見据えている場合、以下が望ましい
モジュール性の維持
最小減な再利用
浅い継承ツリー
各レイヤー内でロジックが実行されず、リクエストが層を素通りしていく
単なるバケツリレーになってしまう
takasshii.iconなんもしないinterface作りがち
これは全てのレイヤードアーキテクチャで少なからず発生
対処
ロジックを経ずに素通りしているリクエストの割合を計測
概ね80%以上が素通りなら、不適である
全てのレイヤーを開放レイヤーにすることで対処可能
変更の困難さとトレードオフ
takasshii.icon開放レイヤーにするのか👀
takasshii.iconUseCaseいるかいらないか論争は80%以上素通りならいらないって判断しても良さそう？
レイヤードアーキテクチャを採用する理由
小規模なアプリケーションやWebサイトに適する
naoya.iconハッカソン！
予算と時間に厳しい制約がある場合の出発点として優れる
ビジネスニーズや要件の分析中で、アーキテクチャスタイルの判断が下せない時、レイヤードアーキテクチャから始めることも良い選択肢の一つ
大きなアプリケーションでは注意が必要
保守性、アジリティ、テスト容易性、デプロイ容易性に悪影響を及ぼす
アーキテクチャ特性の評価
table:layerd
分割タイプ 技術
量子数 1(モノリシック)
デプロイ容易性 ☆
弾力性 ☆
進化性 ☆
耐障害性 ☆
モジュール性 ☆
全体的なコスト（の安価さ） ☆☆☆☆☆
パフォーマンス ☆☆
信頼性 ☆☆☆
スケーラビリティ ☆
シンプルさ ☆☆☆☆☆
テスト容易性 ☆☆
優れる点
コストの安価さとシンプルさ
非常に高い評価
モノリシックであるため、分散型のような複雑さを持たない
構築と保守にかかるコストが低い
アプリケーションが大きくなるにつれて複雑化することには注意
信頼性
中程度の評価
takasshii.iconこれ信頼性になるんだ
劣る点
デプロイ容易性、テスト容易性
モノリシックであるため、少量の変更で全体を再デプロイ、再テストする必要がある コンポーネントやレイヤごとのモックやスタブによって、テスト容易性は多少確保することも可能
弾力性、スケーラビリティ
takasshii.iconここみんな苦労してるのにAndroidみんなレイヤードだよねw
takasshii.icon確かにスケールするかわかんないか
パフォーマンス
アーキテクチャに自然に従うだけでは高パフォーマンスを確保できない
キャッシュ、マルチスレッドなどの利用によって対処は可能
アーキテクト、開発者の努力が必要
耐障害性
一部が落ちると全体が落ちる
応用
https://scrapbox.io/files/655400f89f28e0001cdcbd53.png
UI Layerがプレゼンテーション層
Domain Layerがビジネス層
Data Layerのうち、
Repositoriesが永続化層
Data SourcesがDB層
質疑応答
takasshii.iconService層ってどんなんが入るんだろうな
ドメインの共通ロジックとかか（自己解決）
takasshii.iconUIの共通コンポーネントとかデザインシステムは層が分かれないんかな
なんでドメイン層だけ分かれるんだろう
ロジックじゃ無いからかな
takasshii.iconデータの流れで見るのね
ZOZOのインターン行きてぇ～
これって層ごとにファイルを切ったほうが良いのかな
全レイヤーで使うマジックナンバーってほぼほぼないか👀