Download as PDF, PPTX
![第1部 基本編の構成(1)
• 概論 [第1回]
• 開発プロセス [第2回]
• 基本モデル [第3回]
• 静的モデル(1) [第4回]
• 静的モデル(2) [第5回]
• 動的モデル [第6回]
• 協調モデル [第7回]
• 関数モデル [第8回]
• 物理モデル [第9回]
• 作業分野 [第10回]
• ビジネス・モデリング [第11回]
• 要求 [第12回]
• 要求/ユースケース [第13回]
• 要求/シナリオ [第14回]
• 分析 [第15回]
• 分析/コンポーネント分析 [第16回]
• 分析/イベント駆動 [第17回]
• 作業分野
• 設計 [第18回]
• 設計/アーキテクチャ設計 [第19回]
• 設計/コンポーネント設計(1) [第20回]
• 設計/コンポーネント設計(2) [第21回]
• 設計/コンポーネント設計(3) [第22回]
• 設計/ドメイン設計(1) [第23回]
• 設計/ドメイン設計(2) [第24回]
• 設計/ドメイン設計(3) [第25回]
• 設計/ドメイン設計(4) [第26回]
• 設計/ドメイン設計(5) [第27回]
• 設計/原理 [第28回]
• 設計/ UX/UI設計 [第29回]
• 実装(1) [第30回]
• 実装(2) [第31回]
• 実装(3) [第32回]
• テスト [第33回]](https://image.slidesharecdn.com/threetier-240421214525-50488696/75/34-3-2048.jpg)
![第1部 基本編の構成(2)
• アプリケーション・アーキテクチャ [第34回]
• ドメイン・モデル [第35回]
• アプリケーション・モデル [第36回]
• プレゼンテーション・モデル [第37回]
• ケーススタディ[第38回]
• 要求モデル [第39回]
• 分析モデル [第40回]
• 設計モデル [第41回]
• 実装 [第42回]
• テスト [第43回]](https://image.slidesharecdn.com/threetier-240421214525-50488696/75/34-4-2048.jpg)
![原理 (Principle)
• Agile Software Development [ASD]
• SRP (The Single Responsibility Principle)
• OCP (The Open-Close Principle)
• LSP (The Liskov Substitution Principle)
• …
• GRASP (General Responsibility Assignment Software Patterns or principles)
• Low Coupling
• High Cohesion
• …
• Writing Effective Use Cases [WEUC]
• Scope
• …](https://image.slidesharecdn.com/threetier-240421214525-50488696/75/34-6-2048.jpg)
![パターン (Pattern)
• Design Patterns [DP]
• Observer, Strategy, …
• Domain Driven Design [DDD]
• Ubiquitous Language, Intention-
Revealing Interfaces, …
• Analysis Patterns [AP]
• Party, Quantity, …
• Pattern-Oriented Software
Architecture [POSA]
• Layers, Pipes and Filters, …
• Patterns of Enterprise
Application Architecture [PEAA]
• Unit of Work, Data Transfer Object,
…
• Enterprise Integration Patterns
[EIP]
• Message Bus, Aggregator, …
• Patterns for Effective Use
Cases [PEUC]
• CompleteSingleGoal,
VerbPhraseName, …
• AntiPatterns [AnP]
• Stovepipe System, Analysis
Paralysis, …](https://image.slidesharecdn.com/threetier-240421214525-50488696/75/34-7-2048.jpg)
![Pattern-Oriented Software Architecture
[POSA]
• Layers
• Pipes and Filters
• Blackboard
• Broker
• Model-View-Controller (MVC)
• Presentation-Abstraction-Control (PAC)](https://image.slidesharecdn.com/threetier-240421214525-50488696/75/34-11-2048.jpg)
![DI (Dependency Injection)
• IoC (Inversion of Control)
• 依存性の注⼊
• コンポーネント(オブジェクト)が必要とするコンポーネント(オブジェクト)
への参照作成を⾃ら⾏わず、外部から設定する
• 狙い
• コンポーネント(オブジェクト)間を疎結合[Low Coupling]にする
• 部品としての再利⽤性を⾼める
• テスト容易性を⾼める
• 注⼊のタイミング
• コンポーネント(オブジェクト)作成・組み⽴て時
• オペレーション(メソッド)呼び出し時
再掲 第20回 設計/コンポーネント設計(1)](https://image.slidesharecdn.com/threetier-240421214525-50488696/75/34-19-2048.jpg)
![論点
• 粒度
• Bounded Context [DDD]、SubSystem、Domain Object、Backlog Itemなど
• 粒度が⼩さくなると開発は⼤変になる
• 本講座ではBounded Context [DDD]、SubSystemを採⽤
• 技術
• 分散システム
• 必然的に分散システムになる
• 本質的に開発の難易度が上がる
• トランザクション
• マイクロサービス間でトランザクションの共⽤が難しい
• 補償処理が必要になる
• 実⾏コンテキスト
• ユーザー情報やセキュリティ情報などの共有に⼯夫が必要
再掲 第32回 設計/実装(3)](https://image.slidesharecdn.com/threetier-240421214525-50488696/75/34-36-2048.jpg)
Uploaded byTomoharu ASAMI
アプリケーション・アーキテクチャ 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第34回】
MaruLaboの浅海ゼミでの講座のスライドです。 https://www.marulabo.net/docs/asami34/ 今回からクラウド・アプリケーションのアプリケーション・アーキテクチャの概要と オブジェクト指向分析設計との連携方法について整理していきます。 今回は全体像について説明しました。 次回以降にドメイン層、アプリケーション層、プレゼンテーション層について詳細に見ていきます。
アプリケーション・アーキテクチャ 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第34回】
- 1.
- 2. SimpleModeling2021 • オブジェクト指向分析設計での共通範囲 • UML/UP •本講座で使⽤するUMLプロファイル • プロファイル：SimpleModeling2021 (SM2021) • オブジェクト指向分析設計の基本からの拡張部を明確化 • アジャイル開発 • Communication • Embrace Change • Travel Light • Scaling • Component-Based Development • クラウド・アプリケーション • モデル駆動開発 SM2021 Travel Light Embrace Change Cloud Model-Driven Scaling CBD Testability Serviceability • ⾮機能要件 • Testability • Serviceability
- 3. 第1部 基本編の構成(1) • 概論[第1回] • 開発プロセス [第2回] • 基本モデル [第3回] • 静的モデル(1) [第4回] • 静的モデル(2) [第5回] • 動的モデル [第6回] • 協調モデル [第7回] • 関数モデル [第8回] • 物理モデル [第9回] • 作業分野 [第10回] • ビジネス・モデリング [第11回] • 要求 [第12回] • 要求/ユースケース [第13回] • 要求/シナリオ [第14回] • 分析 [第15回] • 分析/コンポーネント分析 [第16回] • 分析/イベント駆動 [第17回] • 作業分野 • 設計 [第18回] • 設計/アーキテクチャ設計 [第19回] • 設計/コンポーネント設計(1) [第20回] • 設計/コンポーネント設計(2) [第21回] • 設計/コンポーネント設計(3) [第22回] • 設計/ドメイン設計(1) [第23回] • 設計/ドメイン設計(2) [第24回] • 設計/ドメイン設計(3) [第25回] • 設計/ドメイン設計(4) [第26回] • 設計/ドメイン設計(5) [第27回] • 設計/原理 [第28回] • 設計/ UX/UI設計 [第29回] • 実装(1) [第30回] • 実装(2) [第31回] • 実装(3) [第32回] • テスト [第33回]
- 4. 第1部 基本編の構成(2) • アプリケーション・アーキテクチャ[第34回] • ドメイン・モデル [第35回] • アプリケーション・モデル [第36回] • プレゼンテーション・モデル [第37回] • ケーススタディ[第38回] • 要求モデル [第39回] • 分析モデル [第40回] • 設計モデル [第41回] • 実装 [第42回] • テスト [第43回]
- 5. 本講座のアプローチ • オブジェクト指向分析設計の基本を確認 • UML+ UP(Unified Process) • CBD (Component-Based Development) • 最新技術でアップデート • クラウド・コンピューティング • イベント駆動、分散・並列 • ビッグデータ、AI、IoT • コンテナ • 関数型 • OFP(Object-Functional Programming), Reactive Streams • ルール, AI • DevOps • アジャイル開発 • DX (Digital Transformation) 第25回 アプリケーション・アーキテクチャ 第2回 開発プロセス 第9回 物理モデル 第11回 ビジネス・モデリング 第2部 クラウド・アプリケーション編 第21回 設計/ドメイン設計 第20回 設計/コンポーネント設計 第2部 クラウド・アプリケーション編
- 6. 原理 (Principle) • AgileSoftware Development [ASD] • SRP (The Single Responsibility Principle) • OCP (The Open-Close Principle) • LSP (The Liskov Substitution Principle) • … • GRASP (General Responsibility Assignment Software Patterns or principles) • Low Coupling • High Cohesion • … • Writing Effective Use Cases [WEUC] • Scope • …
- 7. パターン (Pattern) • DesignPatterns [DP] • Observer, Strategy, … • Domain Driven Design [DDD] • Ubiquitous Language, Intention- Revealing Interfaces, … • Analysis Patterns [AP] • Party, Quantity, … • Pattern-Oriented Software Architecture [POSA] • Layers, Pipes and Filters, … • Patterns of Enterprise Application Architecture [PEAA] • Unit of Work, Data Transfer Object, … • Enterprise Integration Patterns [EIP] • Message Bus, Aggregator, … • Patterns for Effective Use Cases [PEUC] • CompleteSingleGoal, VerbPhraseName, … • AntiPatterns [AnP] • Stovepipe System, Analysis Paralysis, …
- 8. 内容 • アプリケーション・アーキテクチャ • CBD •三層アーキテクチャ • Hexagonal Architecture • Microservice • Cloud Native Architecture
- 9.
- 10. アプリケーション・アーキテクチャ • クラウド・アプリケーションのアプリケーション・アーキテク チャについて考察 • OOADとの関係を整理 •「基本」、「作業分野」で登場したアーキテクチャに関する情報を整 理
- 11. Pattern-Oriented Software Architecture [POSA] •Layers • Pipes and Filters • Blackboard • Broker • Model-View-Controller (MVC) • Presentation-Abstraction-Control (PAC)
- 12.
- 13. UP (Unified Process) •『The Unified Software Development Process』 • 1990年代に乱⽴したオブジェクト指向開発プロセスを統⼀ • UMLが前提とするリファレン・スモデル • CBD (Component-Based Development) • アーキテクチャ • ユースケース駆動 (use-case driven) • 反復漸進 (iterative/incremental) • アーキテクチャ中⼼ (architecture centric) • ⼯程管理⽅式 • 計画駆動 • ⽂書中⼼ 第2回 開発プロセス 再掲 第5回 静的モデル (2)
- 14.
- 15.
- 16. コンポーネント (Component) • 再利⽤可能な部品 •明確な外部インタフェースを定め実装を隠蔽 • 新規開発を抑えることで開発期間短縮、品質向上を図る • 再利⽤性の⾼い部品化は⾃然にできることではないので、コストを掛けて積極的に狙い に⾏く • 論理モデルと物理モデルの両⽅の性質を兼ね備える • 配備の単位 • 物理的な側⾯ ⇒ モジュール • オブジェクト指向分析設計による開発の様々な側⾯を集約してパッケージ化 • モデリングとプログラミングの結節点 • モデリングはコンポーネントまで。コンポーネントの実現はプログラミングで。 • 再利⽤可能な部品にするための仕掛けが必要 • コンポーネント・フレームワーク • 実⾏コンテキスト Travel Light Travel Light 再掲 第5回 静的モデル (2)
- 17. オブジェクト指向分析設計の様々の側⾯ をコンポーネントに集約 • 機能の単位 • 機能を凝集(coherent)して実現 •開発の単位 • コンポーネント単位で開発の管理を ⾏う • 開発⼯程、担当者など • モデリングの単位 • コンポーネントの実現はプログラミ ングで • 運⽤の単位 • 配備の単位 • バージョン管理 • 仕様書・マニュアルの単位 • 外部仕様、マニュアルの作成 • テストの単位 • テスト仕様の作成単位 • テストの進捗管理の単位 • 障害調査の単位 • 障害発⽣箇所の特定 • 障害調査マニュアルの作成 • 販売・課⾦の単位 • 再利⽤可能な商品 Scaling 再掲 第5回 静的モデル (2)
- 18. コンポーネント仕様 (Component Specification) •インタフェース • 提供インタフェース (Provided Interface) • 要求インタフェース (Required Interface) • レセプション • イベント • ⽣成 • ファクトリ • DI (Dependency Injection) • 拡張点 • 変化点 • メトリックス (Metrics) • データ分析 再掲 第21回 コンポーネント設計 (2)
- 19. DI (Dependency Injection) •IoC (Inversion of Control) • 依存性の注⼊ • コンポーネント(オブジェクト)が必要とするコンポーネント(オブジェクト) への参照作成を⾃ら⾏わず、外部から設定する • 狙い • コンポーネント(オブジェクト)間を疎結合[Low Coupling]にする • 部品としての再利⽤性を⾼める • テスト容易性を⾼める • 注⼊のタイミング • コンポーネント(オブジェクト)作成・組み⽴て時 • オペレーション(メソッド)呼び出し時 再掲 第20回 設計/コンポーネント設計(1)
- 20. サービス (Service) • コンポーネントの⼀種 •副作⽤を起こすというより値 を返す、状態を持たない (stateless)、関数的な (functional)コンポーネント • 実⽤的にはサービスそのものは 状態を持たないが、サービスか ら呼び出されるコンポーネント での副作⽤は発⽣する、という 解釈でよさそう 再掲 第5回 静的モデル (2)
- 21. サブシステム (Subsystem) • コンポーネントの⼀種 •システムを分割した⼤きな単 位 • システム規模が⼤きい場合に サブシステムに分割して開 発・管理 • 『コンポーネントに集約』で 説明したコンポーネントの各 種性質を⼤きな単位で管理す る 再掲 第5回 静的モデル (2)
- 22. システム (System) • サブシステムの⼀種 •コンポーネントの⼀種 • UMLでは⼀番外側のサブシス テムをシステムと考える、と いう定義 再掲 第5回 静的モデル (2)
- 23.
- 24.
- 25. Model-View-Controller (MVC) • UI操作のためのアーキテクチャ・パターン •構成 • Model • UI操作の対象となるモデル • View • 画⾯の表⽰ • Controller • UI操作のイベントの受け付けと操作 • 関連 • WebMVC
- 26. Presentation-Abstraction-Control (PAC) • サービス実現のためのアーキテクチャ・パターン •構成 • Presentation • 外部表現(インタフェース、ポート) • Abstraction • 操作対象となるモデル • Control • 操作
- 27.
- 28.
- 29.
- 30. Hexagonal Architecture • 別名 •Port and Adapter Architecture • Onion Architecture • 関連 • Clean Architecture • 三層構造を全⽅位にして汎⽤化 • イベント駆動にも対応
- 31.
- 32.
- 33. OOADの観点から • CBDによる開発で⾃然にHexagonal Architectureになるのがよ い •Event-Driven Architecture, Reactive Architectureの実現に活 ⽤
- 34.
- 35. マイクロサービス • マイクロサービスとは: • 1つのアプリケーションをビジネス機能に沿った複数の⼩さいサービス を疎結合した集合体として構成するアーキテクチャ •SOA( Service-oriented Architecture)の⼀種と考えられる • ⽂脈 • ハードウェア性能の向上 • クラウド・プラットフォーム • アジャイル開発 • 基盤技術 • CI/CDパイプライン • CBD 再掲 第32回 設計/実装(3)
- 36. 論点 • 粒度 • BoundedContext [DDD]、SubSystem、Domain Object、Backlog Itemなど • 粒度が⼩さくなると開発は⼤変になる • 本講座ではBounded Context [DDD]、SubSystemを採⽤ • 技術 • 分散システム • 必然的に分散システムになる • 本質的に開発の難易度が上がる • トランザクション • マイクロサービス間でトランザクションの共⽤が難しい • 補償処理が必要になる • 実⾏コンテキスト • ユーザー情報やセキュリティ情報などの共有に⼯夫が必要 再掲 第32回 設計/実装(3)
- 37. マイクロサービスの前提 • マイクロサービスを機能させるためには、各種の前提を満たす 必要がある • 開発プロセス •アジャイル開発 • 開発組織 • ⼩規模、疎結合、多機能チームのネットワーク • ソフトウェア・アーキテクチャ • 疎結合、テスト可能(testable)、配備可能(deployable) 再掲 第32回 設計/実装(3)
- 38. マイクロサービスの⻑所と短所 • ⻑所 • 可⽤性(availability) • 柔軟性 (resiliency) • モジュール性 (modularity) • 凝集性 (cohesion) • 関⼼の分離 (separation of concern) • 抽象性 (abstraction) • 結合性 (coupling) • 短所 • 開発の難易度が上がる • 性能低減 • 開発効率低減 再掲 第32回 設計/実装(3)
- 39.
- 40. アーキテクチャ ⽐較 Modular Monolith ? 再掲第32回 設計/実装(3)
- 41. 本講座のアプローチ • CBDを軸に開発を進める • マイクロサービス化の必要条件 •CI/CDパイプライン • アジャイル開発 • ネットワーク型の開発組織 • マイクロサービス化の要件 • 可能性 (availability) • 柔軟性 (resiliency) SM2021 再掲 第32回 設計/実装(3)
- 42.
- 43. Cloud Native Architecture •Cloud環境を活⽤したアプリケーション・アーキテクチャ • Cloud Native Computing Foundation • https://www.cncf.io/
- 44. Message-Driven Architecture • メッセージの送受信でシステムを駆動 •Reactive Architecture • Pipes and Filters • Message Brokerでメッセージの振り分けを⾏う • Broker
- 45. Event-Driven Architecture • イベントの発⾏でシステムを駆動 •Reactive Architecture • Event Brokerでイベントの振り分けを⾏う • Broker • Event Sourcing • イベント列の記録でリソースの状態を永続化 • EventStorming • イベントを軸にワークショップ形式でモデリングを⾏う⼿法
- 46. CQRS • Command QueryResponsibility Segregation • コマンドクエリ責務分離 • リソース操作の参照と更新を分離して⾮対称にする • CRUDによる対称的なインタフェースとは別の戦略 • 更新系は⾮同期(ジャーナルなどの⼿法を活⽤) • 更新結果は直接返ってこない • ⽤途 • 参照と更新でセマンティクスや粒度が異なる場合 • リソースの更新性能の向上 • スケーラビリティの向上
- 47. Event Sourcing • リソースの状態をイベントの列の記録によって永続化 •ドメイン・モデルのキー要素であるイベントを活⽤ • イベントは不変オブジェクトとしてデータ・ストアに追記 • 処理の記録を残すことができる • 処理の復元が可能になる • ⽤途 • リソースの更新性能の向上 • スケーラビリティの向上 • 可⽤性の向上 • 注意点 • イベント列による処理の復元は、時間、乱数、外部サービスといった要因が あると完全に⾏うことができるわけではない
- 48.
- 49. テスト容易性 (Testability) • コンポーネントのテストのしやすさ •他のコンポーネントとの依存性をできるだけ排除する • インタフェース(提供、要求)を通してアクセス • コンポーネントの作成はDI(Dependency Injection)を可能にす る • クライアントの実⾏⽂脈は実⾏コンテキスト経由で取得するよ うにする • 認証情報、時間 • コンポーネントの内部情報がテスト・プログラムから取得でき るようにする 再掲 第21回 コンポーネント設計 (2)
- 50.
- 51.
- 52.
- 53.
- 54. Security • アーキテクチャ設計の中で以下の機能の実現⽅法を考える必要 がある • 認証(authentication) • 認可 (authorization) • 監査 (audit) • DMZ (Demilitarized zone)
- 55. OOADの観点から • 認証 • アクター(外部エンティティ)からのアクセスには認証が必要 •認可 • 認可の対象となるエンティティを検討 • 監査 • イベントによる動作記録を軸に考える
- 56.
- 57. DevOps • ソフトウェア開発(Dev)とITオペレーション(Ops)を結合するプ ラクティスの集まり。 • システム開発の短縮を⽬的とし⾼品質ソフトウェアの継続デリ バリーを提供。 •共同所有、ワークフロー・オートメーション、迅速なフィード バック • 組織⽂化の変化まで視野に⼊るスケールの枠組み • ツールの活⽤が前提 • CI/CD Pipeline • DevOps as a Service 第9回 物理モデル 再掲
- 58.
- 59. 保守性 (Serviceablity) • コンポーネントの維持管理のしやすさ •コンポーネントのバージョン管理 • コンポーネントを構成するソースコードやマニュアルを⼀元管 理する • 管理に必要なコンポーネントの内部状態を取得可能にする • コンポーネントのチューニングに必要なメトリクスを採取する 再掲 第21回 コンポーネント設計 (2)
- 60.
- 61.
- 62. Observability / Monitoring •Monitoring • 各種メトリクスの表⽰と閾値によるアラーム • Observability • 観測データの蓄積と問い合わせ • 基本機能 • トレース • メトリクス • ログ • OpenTelemetry • https://opentelemetry.io/
- 64. OOADの観点から • イベントを観測対象にすることでシステムの振る舞いの⾒える 化 • アプリケーション・モデル、ドメイン・モデルで定義した各種 エンティティを観測対象にしたい •設計上の各種メトリクスの定義と観測対象化 • キャッシュのヒット率、⾮同期処理の実⾏時間… • ビジネス・モデルのKGI(Key Goal Indicator)、KPI(Key Performance Indicator)を観測対象にすることでビジネス上の 振る舞いを⾒える化
- 65. まとめ • 伝統的なアーキテクチャ • 三層アーキテクチャ •Hexagonal Architecture • Cloud Native Architecture • Event-Driven Architecture • Observability • OOADとクラウド・アプリケーション・アーキテクチャをつな ぐ技術 • CBD • イベント
- 66. 参考⽂献 • The UnifiedModeling Language Reference Manual, 2nd (Rumbaugh他, 2004) • The Unified Modeling Language User Guide, 2nd (Booch他, 2004) • The Unified Software Development Process (Jacobson他, 1999) • The Object Constraint Language, 2nd (Warmer 他, 2003) • UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (Arlow 他, 2005) • OMG Unified Modeling Language Version 2.5 (OMG, 2015) • 上流⼯程UMLモデリング (浅海, 2008) • Pattern-Oriented Software Arhitecture: A System of Patterns (Buschamnn他, 1996) • Design Patterns for Cloud Native Applications: Patterns in Practice Using APIs, Data, Events, and Streams (Indrasiri他, 2021) • Building Event-Driven Microservices: Leveraging Organizational Data at Scale (Bellemare, 2020) • Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture (Vernon他, 2021) • Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka (Vernon, 2015) • Observability Engineering (Majors他, 2022)