History of Architecture

※こちらのスライドはSlidevで作成されており、以下のURLでアニメーション付きでご覧頂けます。

https://kazu-kichi-67.github.io/slidev-history-of-architecture/1

■ 概要

2024/8/1 社内勉強会向けスライド

みなさん、今携わっているプロジェクトのアーキテクチャについて、どこまで理解できていますか？

担当している案件や機能、目の前のクラスだけに手一杯になってしまって、
システムの全体像が見えていないと先輩エンジニアに指摘された方も多いのではないでしょうか。

このスライドでは、アーキテクチャのメリット・デメリットに着目しながら、なぜそのアーキテクチャが流行ったのか、また、どんな課題感があって次のアーキテクチャが生まれたのか、アーキテクチャの変遷を辿りながら解説します。

アーキテクチャを知ることで、システムの全体像が把握しやすくなるだけでなく、システムの設計思想を知ることによって、アンチパターンを避け、コードの品質向上にも寄与することが出来ます。

また、後半では今トレンドと思われるアーキテクチャについて解説します。

現プロジェクトで扱うアーキテクチャは把握できているが、トレンドまでキャッチアップできていない中堅エンジニアの方にも、これから情報収集を行う最初の一歩となる内容にしたいと思います。

■ アジェンダ
・アーキテクチャの変遷
　・システム全体
　　→モノリス、マイクロサービス、モジュラモノリス
　・フロントエンド
　　→MVC、MVP、MVVM
　・バックエンド
　　→レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャ、オニオンアーキテクチャ、クリーンアーキテクチャ、ドメイン駆動設計
・トレンド
　・CQRS
　・イベントソーシング

■ 話さないこと
・アーキテクチャごとの詳細な説明
・そのアーキテクチャを実現するためのフレームワークや特定のサービスについての詳細な説明
・自分がアーキテクチャを認識できるようになる前のお話（直近10年以内の話になると思います）

Transcript

1. History of Architecture @kazu_kichi_67 2024/08/01 presentation for 社内勉強会
2. 1 / 25 Who am i? Name - kazu_kichi_67 Language - Java (, Kotlin, Swift, PHP, C++) Skill - Registered Scrum Master Hobby - フットサル, スノボ, 爬虫類, キャンプ, サウナ, ウイスキー, クラ フトビール, 筋トレ, 英語 Interest - Scrum, DDD, Architecture, Observability, Cloud Native, Platform Engineering, AI, Golang, Rust
3. 2 / 25 Agenda 1. アーキテクチャーの変遷 1. システム全体編 2. フロントエンド編 3. バックエンド編 2. トレンド 1. CQRS 2. Event Scourcing
4. 3 / 25 はじめに アーキテクチャの思想を知ることの重要性 システムの理解を早める アンチパターンを避ける 保守性、品質、開発効率の向上 上流工程への参画 市場価値の向上 2025年の崖 既存システムのレガシーシステム化 リプレイス案件の増加が予想される IT人材不足 人が多ければいいってもんじゃない 最新トレンドに沿った、リアーキテクティングのスキルが重要 今、本当に現場で求められているスキルを学びましょう
5. 4 / 25 注意点 情報量が多いので、この場で全てを理解するのは難しいと思います 頻出単語の関連性や、IT業界全体の流れを把握し、今後の勉強の足掛かりにしてほしい
6. 5 / 25 アーキテクチャーの変遷
7. 6 / 25 システム全体編
8. 7 / 25 モノリス モノリス メリット デメリット 1つのアプリケーションのため、デプロイが容易 スタートアップであれば、これで十分な場合も多い アプリケーションが多くなればなるほど複雑化しやすい（Big Ball of Mat: 大きな泥団子） 修正に対する影響範囲が広く、開発スピードが低下する 影響範囲の特定すら難しく、サービス品質が低下する 機能毎にスケールすることが出来ない（弾力性×） 1つのアプリケーションがダウンすると、そのままサービス停止へ（耐障 害性×）
9. 8 / 25 マイクロサービス マイクロサービス マイクロサービス マイクロサービス メリット デメリット 機能毎に疎結合となり、互いに修正の影響を受けづらい 機能単位でのデプロイ、スケーリングが可能 障害の影響を最小限にできる コンテナ環境と相性が良い デプロイ、サービス管理のコストが高い マイクロサービス間通信によるオーバーヘッド 解析時に流れを追うのが難しい トランザクションを貼れないため、データの一貫性を担保しづらい sagaパターン マイクロサービス間の境界を見極めるのが難しい
10. 9 / 25 モジュラモノリス モジュラモノリス メリット デメリット マイクロサービスのデメリットを緩和できる デプロイ、サービス管理のコストが低め モジュール間のやり取りでオーバーヘッドが少ない オーケストレーター層を置いてトランザクション管理することも可能 モジュール間の境界を見誤っても、リカバリしやすい マイクロサービスほど自由にスケール出来ない モジュール境界の管理をしっかりやらないと、モノリスと変わらなくなる マイクロサービスとモジュラモノリスのハイブリットもおすすめ。 組織のス ケールに合わせて少しずつマイクロサービスへ移行する！
11. 10 / 25 フロントエンド編
12. 11 / 25 MVC Controller Model View Controller Model View メリット デメリット Classic MVC、MVC 2とか存在する Controllerが入力を受け付けて、Model-Viewの橋渡しを行う Struts、Spring MVC、Laravel、CakePHP、FuelPHP、Ruby on Rails View（画面のレイアウト）とModel(ビジネスロジックやデータ管理)を分 離できる 同じModelでViewだけ切り替えることが可能 大規模アプリケーションでは、Controllerが肥大化しやすい ViewとModelの結合度が高くなりがち
13. 12 / 25 MVP Presenter Model View Presenter Model View メリット デメリット PresenterがModelとViewの仲介を行う Presenterがイベントハンドリングを担う ViewがModelの変更を監視する(Observe)パターン パッシブビュー(Passive View) パッシブビューによって完全にViewと分離できるので、よりテストがしや すい Presenterが肥大化しやすい ViewとPresenterの1対1の関係が必要で、柔軟性に欠ける場合がある
14. 13 / 25 MVVM ViewModel Model View メリット デメリット データバインディング React.js: 単方向バインディング、Vue.js: 双方向バインディング MVPとそこまで変わらないが、ViewとViewModelの連携をフレームワー クが担ってくれる 最初の学習コストが高い
15. 14 / 25 バックエンド編
16. 15 / 25 レイヤードアーキテクチャ レイヤードアーキテクチャ プレゼンテーション（インターフェース）層 ユースケース(アプリケーション)層 ドメイン(ビジネスロジック)層 インフラストラクチャー（データアクセス）層 ※ 矢印は依存の向き ※ 3層の場合もある（層の数に決 まりはない） メリット デメリット 各層に特定の役割（責務）を与えることで、コードの見通しが良くなる （単一責任の原則 SRP） 上層の変更に対して、下層が影響を受けない 使い回しが出来る 下層の変更によって、上層が影響を受ける つまり、インフラストラクチャーを変更すると、ビジネスロジックが影響 を受けてしまう
17. 16 / 25 ヘキサゴナルアーキテクチャ Port Application Adapter Adapter DB Adapter Adapter Client Client 依存性逆転の原則(DIP) プレゼンテーション層 ユースケース層 ドメイン層 インフラストラクチャー層 メリット デメリット 別名、Ports and Adapters Port層によってApplicationが守られているので、外部の変更に対して強い Application（ビジネスロジック）の独立性が高く、テストが容易 初期の設計が複雑になりがち 小規模なシステムだと過剰な設計になりうる
18. 17 / 25 オニオンアーキテクチャ Domain Model Domain Service Application Service Infrastructure UI Tests メリット デメリット ドメインを中心にして設計される 外から中への依存 ドメインが何にも依存せず、外側の影響を受けない テストが容易 ビジネスロジックの再利用性が高い 小規模なシステムには不向き
19. 18 / 25 クリーンアーキテクチャ メリット デメリット ドメイン（エンティティ）を中心にして設計される 外から中への依存 テストが容易 フレームワークやデータベースの変更に強い ビジネスロジックの明確な分離 小規模なシステムだと、作るものが多く冗長になりうる 初期の学習コストが最も高い
20. 19 / 25 ドメイン駆動設計（DDD） 戦術的DDD 実装パターンやレイヤー設計のパターン Repository、Domain Service、Value Object、Entityなど こちらのみ：軽量DDD 戦略的DDD ドメイン（システムにおける本質的に重要な部分、ビジネスロジック）をモデリングする手法 ユビキタス言語、境界づけられたコンテキスト、ドメインエキスパート、サブドメインなど 手法：イベントストーミング、ユースケース分析、ドメインストーリーテリングなど
21. 20 / 25 トレンド
22. 21 / 25 CQRS
23. 22 / 25 CQRS Command Model Writer Query Model Reader Sync メリット デメリット Command Query Responsibility Segregation: コマンド・クエリ責務分離 複数の集約単位を跨るようなリードモデルが欲しくなる 一覧画面のようなもの、N+1問題 ドメインモデルの最適化 更新系（NoSQL）と参照系（RDB）それぞれスケーリングが可能 データ整合性の管理 結果整合性を受け入れられるか システムが増えるにつれ、管理コストも増加 NewSQLの利用: Cloud Spanner、TiDB、CockroachDB コマンドとクエリの2つのモデル開発、テスト GraphQL等の活用、自動化
24. 23 / 25 Event Scourcing
25. 24 / 25 Event Scourcing Command Model Writer A micro service Reader Event Store B micro service Reader 旧システ ム メリット デメリット CQRSとはセットで語られることがほとんど Axon, Kafka、Amazon Kinesis、SQS、Akkaなど 耐障害性 弾力性 リトライ、履歴、ロールバック、キャッシュ、流量制限等の責務を移譲 高凝縮・疎結合 システムの複雑化、非同期通信による設計難易度 結果のポーリングや、冪等性の担保など 障害時に追いづらい オブザーバビリティが重要 OpenTelemetry、Prometheus、Datadog、New Relic、Dynatraceなど
26. 25 / 25 参考文献 SOLID原則 リアクティブ宣言 CQRSパターン イベントソーシングパターン アーキテクチャ特集
27. End Powered by 良いエンジニアライフを！