History of Architecture @kazu_kichi_67 2024/08/01 presentation for 社内勉強会

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

2 / 25 Agenda 1. アーキテクチャーの変遷 1. システム全体編 2. フロントエンド編 3. バックエンド編 2. トレンド 1. CQRS 2. Event Scourcing

3 / 25 はじめに アーキテクチャの思想を知ることの重要性 システムの理解を早める アンチパターンを避ける 保守性、品質、開発効率の向上 上流工程への参画 市場価値の向上 2025年の崖 既存システムのレガシーシステム化 リプレイス案件の増加が予想される IT人材不足 人が多ければいいってもんじゃない 最新トレンドに沿った、リアーキテクティングのスキルが重要 今、本当に現場で求められているスキルを学びましょう

4 / 25 注意点 情報量が多いので、この場で全てを理解するのは難しいと思います 頻出単語の関連性や、IT業界全体の流れを把握し、今後の勉強の足掛かりにしてほしい

5 / 25 アーキテクチャーの変遷

6 / 25 システム全体編

7 / 25 モノリス モノリス メリット デメリット 1つのアプリケーションのため、デプロイが容易 スタートアップであれば、これで十分な場合も多い アプリケーションが多くなればなるほど複雑化しやすい（Big Ball of Mat: 大きな泥団子） 修正に対する影響範囲が広く、開発スピードが低下する 影響範囲の特定すら難しく、サービス品質が低下する 機能毎にスケールすることが出来ない（弾力性×） 1つのアプリケーションがダウンすると、そのままサービス停止へ（耐障 害性×）

8 / 25 マイクロサービス マイクロサービス マイクロサービス マイクロサービス メリット デメリット 機能毎に疎結合となり、互いに修正の影響を受けづらい 機能単位でのデプロイ、スケーリングが可能 障害の影響を最小限にできる コンテナ環境と相性が良い デプロイ、サービス管理のコストが高い マイクロサービス間通信によるオーバーヘッド 解析時に流れを追うのが難しい トランザクションを貼れないため、データの一貫性を担保しづらい sagaパターン マイクロサービス間の境界を見極めるのが難しい

9 / 25 モジュラモノリス モジュラモノリス メリット デメリット マイクロサービスのデメリットを緩和できる デプロイ、サービス管理のコストが低め モジュール間のやり取りでオーバーヘッドが少ない オーケストレーター層を置いてトランザクション管理することも可能 モジュール間の境界を見誤っても、リカバリしやすい マイクロサービスほど自由にスケール出来ない モジュール境界の管理をしっかりやらないと、モノリスと変わらなくなる マイクロサービスとモジュラモノリスのハイブリットもおすすめ。 組織のス ケールに合わせて少しずつマイクロサービスへ移行する！

10 / 25 フロントエンド編

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の結合度が高くなりがち

12 / 25 MVP Presenter Model View Presenter Model View メリット デメリット PresenterがModelとViewの仲介を行う Presenterがイベントハンドリングを担う ViewがModelの変更を監視する(Observe)パターン パッシブビュー(Passive View) パッシブビューによって完全にViewと分離できるので、よりテストがしや すい Presenterが肥大化しやすい ViewとPresenterの1対1の関係が必要で、柔軟性に欠ける場合がある

13 / 25 MVVM ViewModel Model View メリット デメリット データバインディング React.js: 単方向バインディング、Vue.js: 双方向バインディング MVPとそこまで変わらないが、ViewとViewModelの連携をフレームワー クが担ってくれる 最初の学習コストが高い

14 / 25 バックエンド編

15 / 25 レイヤードアーキテクチャ レイヤードアーキテクチャ プレゼンテーション（インターフェース）層 ユースケース(アプリケーション)層 ドメイン(ビジネスロジック)層 インフラストラクチャー（データアクセス）層 ※ 矢印は依存の向き ※ 3層の場合もある（層の数に決 まりはない） メリット デメリット 各層に特定の役割（責務）を与えることで、コードの見通しが良くなる （単一責任の原則 SRP） 上層の変更に対して、下層が影響を受けない 使い回しが出来る 下層の変更によって、上層が影響を受ける つまり、インフラストラクチャーを変更すると、ビジネスロジックが影響 を受けてしまう

16 / 25 ヘキサゴナルアーキテクチャ Port Application Adapter Adapter DB Adapter Adapter Client Client 依存性逆転の原則(DIP) プレゼンテーション層 ユースケース層 ドメイン層 インフラストラクチャー層 メリット デメリット 別名、Ports and Adapters Port層によってApplicationが守られているので、外部の変更に対して強い Application（ビジネスロジック）の独立性が高く、テストが容易 初期の設計が複雑になりがち 小規模なシステムだと過剰な設計になりうる

17 / 25 オニオンアーキテクチャ Domain Model Domain Service Application Service Infrastructure UI Tests メリット デメリット ドメインを中心にして設計される 外から中への依存 ドメインが何にも依存せず、外側の影響を受けない テストが容易 ビジネスロジックの再利用性が高い 小規模なシステムには不向き

18 / 25 クリーンアーキテクチャ メリット デメリット ドメイン（エンティティ）を中心にして設計される 外から中への依存 テストが容易 フレームワークやデータベースの変更に強い ビジネスロジックの明確な分離 小規模なシステムだと、作るものが多く冗長になりうる 初期の学習コストが最も高い

19 / 25 ドメイン駆動設計（DDD） 戦術的DDD 実装パターンやレイヤー設計のパターン Repository、Domain Service、Value Object、Entityなど こちらのみ：軽量DDD 戦略的DDD ドメイン（システムにおける本質的に重要な部分、ビジネスロジック）をモデリングする手法 ユビキタス言語、境界づけられたコンテキスト、ドメインエキスパート、サブドメインなど 手法：イベントストーミング、ユースケース分析、ドメインストーリーテリングなど

20 / 25 トレンド

21 / 25 CQRS

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等の活用、自動化

23 / 25 Event Scourcing

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など

25 / 25 参考文献 SOLID原則 リアクティブ宣言 CQRSパターン イベントソーシングパターン アーキテクチャ特集

End Powered by 良いエンジニアライフを！