Slide 1

Slide 1 text

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. 徹底解説マイクロサービス Atsushi Fukui J A W S U G 函 館 勉 強 会 V O L . 1 2 Senior Solutions Architect, Developer Specialist Amazon Web Services Japan 〜マイクロサービスのメリット、デメリット、 なぜマイクロサービスを選択するのか〜

Slide 2

Slide 2 text

© 2023, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark ⾃⼰紹介 v名前 v 福井 厚(ふくい あつし)twitter: afukui@ v所属 v アマゾン ウェブ サービス ジャパン合同会社 v シニアソリューションアーキテクト • Developerスペシャリスト - DevAx v関⼼領域 v ソフトウェア アーキテクチャ、オブジェクト指向設計、アジャイル開発 v好きなAWSサービス v サーバーレステクノロジー全般、 AWS Code シリーズ

Slide 3

Slide 3 text

© 2023, Amazon Web Services, Inc. or its affiliates. Agenda • マイクロサービスとは • なぜマイクロサービスアーキテクチャを採⽤するのか • マイクロサービスに適した組織 • マイクロサービスのアンチパターン • どうやってサービスを分割するのか • ドメイン分割のためのEvent Storming • まとめ

Slide 4

Slide 4 text

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスとは

Slide 5

Slide 5 text

© 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスとは • ビジネスドメインに基づいて分割された、独⽴してデプロイ可能なサービス 映画情報 サービス 料⾦サービス 通知サービス 予約サービス 発送サービス 課⾦サービス 料⾦情報の 問い合わせ 上映⽇イベント 予約情報 問い合わせ

Slide 6

Slide 6 text

© 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスの重要な概念 『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022

Slide 7

Slide 7 text

© 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスの性質 疎結合で、独⽴性が⾼い • 独⽴してデプロイ可能 • つまり各サービスが疎結合 • ビジネスモデルの境界に沿って分割 • Web 三層 ⇔ ドメインモデル • 技術的な境界に沿って分割しない • 変更要求に対し、複数のサービスを横断して デプロイすることになる • 各サービスが⾃⾝でデータを所有する • データベースを共有しない • データはWeb APIやイベントなどで受け渡す 『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022

Slide 8

Slide 8 text

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. なぜマイクロサービスアーキテクチャ を採⽤するのか

Slide 9

Slide 9 text

© 2022, Amazon Web Services, Inc. or its Affiliates. 7割 33 年 企業を取り巻く環境の変化 1964 年 ⽼朽システムが、DXの⾜かせ になっていると感じている S&P 500 の企業の平均寿命 12 年 2027 年 出典: Innosight 「2018 Corporate Longevity Forecast」 出典:経済産業省 「DX レポート」 https://www.meti.go.jp/press/2018/09/20180907010/20180907010-2.pdf レガシーが⾜かせ

Slide 10

Slide 10 text

© 2022, Amazon Web Services, Inc. or its Affiliates. 書店︖ タクシー︖ DVD︖ 業界の再定義 ホテル︖ 気分や⽬的に合わせた 宿泊体験 不安、⾯倒のない タクシー移動 いつでもどこでも 娯楽を提供 世界最⼤の 宿泊サービス提供 世界最⼤規模の配⾞事業 世界有数の エンターテイメント 世界最⼤規模の EC で 品揃え・低価格・利便性を提供 Amazon Account を使⽤し ⾳楽・映画等のサービス提供

Slide 11

Slide 11 text

© 2022, Amazon Web Services, Inc. or its Affiliates. 『 』 “…innovation is now recognized as the single most important ingredient in any modern economy…” イノベーション こそが近代経済において 最も重要な要素と考えられている。 競合よりも早く、新しい波を 創っていくことが重要

Slide 12

Slide 12 text

© 2022, Amazon Web Services, Inc. or its Affiliates. イノベーションがビジネスを進化させる 新たなマーケット 新たな顧客価値 New economics 新たなデジタル製品とサービス

Slide 13

Slide 13 text

© 2022, Amazon Web Services, Inc. or its Affiliates. Listen Idea Experiment Innovation Flywheel 実験がイノベーションを加速する

Slide 14

Slide 14 text

© 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスに変更する理由 チームの⾃律性 チームの規模が⼩さくなることでコミュニケーションコストが減る ⾃⾝のサービスを完全にコントロールでき、⾃律的⾃発的な機能改善に繋がる アジリティ 各機能を他の機能のリリースを調整せずにリリースできるようになる スケーリング 負荷が⾼い機能のみをスケーリングすることができる 堅牢性 負荷が⾼まったとき、リリースによる障害などの影響が単⼀のサービスにとどまり、アプリケー ション全体としての堅牢性が⾼まる 採⽤技術の柔軟性 各サービス毎に異なる⾔語やアーキテクチャ(VM/コンテナ/サーバーレス/etc)を採⽤できる

Slide 15

Slide 15 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスに適した組織

Slide 16

Slide 16 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. マイクロサービスの組織とチームビルディング • ⾃律的で意思決定する権限と責任を持つチーム • 開発したチームが運⽤も⾏う(You build it, you run it) • Two Pizza Team • すべてを所有

Slide 17

Slide 17 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 参考︓チームトポロジー ストリームアラインドチーム ストリームアラインドチーム ストリームアラインドチーム 共有サービスプラットフォームチーム 内部プラットフォームチーム ][ セキュリティ コミュニティ・オブ・ プラクティス(CoP) プラットフォーム + ツール )( )( フィールドチーム (サポート、ソリューションアーキテクト、営業) O 製品機能のリクエスト ストリームアラインドチーム ビジネスに沿った⽬標を持つチーム イネーブリングチーム ストリームアラインドチームが 障害を克服するのを⽀援。 コンプリケイテッド・ サブシステムチーム 専⾨性が必要な機能を担当する 専⾨スキルを持つチーム コラボレーション ファシリテーション O )( フェデレーションサービス (X-as-a-Service) ][ データ サイエン スチーム サービスとしてのプラットフォーム キー: )( )( ][ * マシュー・スケルトン,マニュエル・パイス. チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (Japanese Edition). Kindle Edition.

Slide 18

Slide 18 text

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark © 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark 1994-2001 2002+ モノリシックアーキテクチャ + 階層化組織 サービスの分割 + Two-pizzaチーム 1000+マイクロサービス 100+ purpose-built databases Amazonにおけるデプロイメント変遷︓2001-2002

Slide 19

Slide 19 text

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark コンポーネントの分割 原則 • 可能な限り⼩さなユニットにする(プリミティブ) • データドメインの作成 • 関数単位ではなくスケールファクタによる分割 • 個々のサービスは独⽴して運⽤ 組織間の連携による待ち時間の発⽣を抑える • サービス間はAPI(契約)で連携 これにより組織の変更が導かれました

Slide 20

Slide 20 text

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark © 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark 組織の再編成の開始 “Two-pizza” teams • サービスを所有 • 制約を最⼩化 (コンウェイの法則) • 意思決定のための⾃⽴した組織

Slide 21

Slide 21 text

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark © 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark 組織の再編成の開始 ひとつのチームでどうやって実⾏するのか? すべてを所有 • 計画 • セキュリティ • パフォーマンス • スケーラビリティ • デプロイメント • 運⽤ • バグ • ⽂書化 • テスト…

Slide 22

Slide 22 text

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark 専任のシングルスレッド化されたチームでフローを最適化 専任の商品担当チーム 商品開発 商品化 商品マネージャー プロジェクトマネージャー 開発者 テスト担当者 インフラ担当者 運営とサポート 商品チーム B 商品チーム A 商品チーム C バックログ A • ストーリー 1 • ストーリー 2 • ストーリー 3 • ストーリー 4 バックログ A • ストーリー 1 • ストーリー 2 • ストーリー 3 • ストーリー 4 バックログ A • ストーリー 1 • ストーリー 2 • ストーリー 3 • ストーリー 4

Slide 23

Slide 23 text

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark スクラムロール例 スクラムマスター、開発者、プロダクトオーナー チームにアジャイルな⽅法論を適⽤ スクラムボード例

Slide 24

Slide 24 text

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark 組織内の “サイロ” 化が勢いを無くす要因 オペレーション データベース チーム 品質保証 アプリケーション セキュリティ ソフトウェア 開発チーム “開発環境のセットアップを 待機するため作業を中断" “新しいテーブルや SQL スクリプトを 待機するため作業を中断" “パフォーマンステストを 待機するために作業を中断" “ ソースコードの⼿動検査を 待機するため作業を中断 " “データベースセキュリティの承認待機するため作業を中断" “セキュリティテストの完了を 待機するため作業を中断" “セキュリティ証明書の作成を 待機するため作業を中断" “データベースホストのセットアップを 待機するため作業を中断" “新しいテストのホストを待機するために作業を中断 ”

Slide 25

Slide 25 text

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark マイクロサービスはDevOpsのスタイルで運⽤すべき オペレーション データベー ス管理者 品質保証 (テスト担当者) アプリケーション セキュリティ ソフトウェア開発 チーム “共働"

Slide 26

Slide 26 text

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスのトレードオフ

Slide 27

Slide 27 text

© 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスのトレードオフ 分散システムに伴う複雑性 ネットワーク呼出による連携となり、モノリシックシステムでメ ソッドを呼び出すときには発⽣しなかった考慮点が発⽣する ネットワークのエラーや遅延、呼出先のダウン、障害発⽣時のトラ ブルシューティングなど 整合性の担保 モノリシックなシステムではトランザクションで容易に強⼒な整合 性を担保できる マイクロサービスで同様の整合性は担保できない マイクロサービスの統廃合やリファクタリングが困難 モノリスではIDEの機能で⾃動的にインターフェースやクラスの分割、 抽出、統合が可能で、データスキーマも整理可能 マイクロサービスでは、そのような統廃合は複数のサービスチーム の調整やデータの移管が必要

Slide 28

Slide 28 text

© 2023, Amazon Web Services, Inc. or its affiliates. トレードオフの対策 分散システムに伴う複雑性 ⾮同期なイベント駆動で連携したり、同期API呼出の場合はサー ビスメッシュを利⽤する 整合性の担保 整合性が必要な単位でマイクロサービスを分割しない どこで整合性が必要なのか、ビジネスのモデリングが必要 サーガパターンなど、結果整合性を担保するデザインパターンを 利⽤する マイクロサービスの統廃合やリファクタリングが困難 統廃合がなるべく発⽣しないよう、ビジネスのモデリングが必要

Slide 29

Slide 29 text

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスのアンチパターン

Slide 30

Slide 30 text

© 2023, Amazon Web Services, Inc. or its affiliates. チーム内に意思決定する権限がない • ビジネス的な価値を提供するために、どの機能を優先的にリリー スするかをチームで決定できない • ユーザーからのフィードバックを受けて何をどのように改善する かを決定できない • チームが自律的に行動できる組織になっていない

Slide 31

Slide 31 text

© 2023, Amazon Web Services, Inc. or its affiliates. 開発メンバーの数がサービスより少ない • 開発者3人で20以上のマイクロサービスを開発しているなど • 開発者がボトルネックとなってリリースや改善の頻度が低下

Slide 32

Slide 32 text

© 2023, Amazon Web Services, Inc. or its affiliates. バックエンドのデータベースを各サービスで共有 • マイクロサービスではない • 密結合になっておりマイクロサービスのメリットが活かせない

Slide 33

Slide 33 text

© 2023, Amazon Web Services, Inc. or its affiliates. サービス単位ではなく機能単位のチーム構成している • UI、アプリケーション、データベース など機能単位にチームが分かれている 「マイクロサービスアーキテクチャ 第2版」オライリージャパン 2022

Slide 34

Slide 34 text

© 2023, Amazon Web Services, Inc. or its affiliates. ドメインをまたがって密結合になっている • ビジネスドメインの境界に従ってサービスが分割されていない • 境界づけられたコンテキスト間はドメインイベントで疎結合にする • 分散システムでは、非同期、結果整合を許容する必要がある

Slide 35

Slide 35 text

© 2023, Amazon Web Services, Inc. or its affiliates. 明確な目的もなくマイクロサービスを選択している • 銀の弾丸ではない • 「流行っているから」「新しい手法だから」という理由でマイクロ サービスアーキテクチャを選択しない • マイクロサービスのもたらす価値と複雑性のトレードオフを考慮

Slide 36

Slide 36 text

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. どうやってサービスを分割するのか

Slide 37

Slide 37 text

© 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスの性質(再掲) 疎結合で、独⽴性が⾼い • 独⽴してデプロイ可能 • つまり各サービスが疎結合 • ビジネスモデルの境界に沿って分割 • Web 三層 ⇔ ドメインモデル • 技術的な境界に沿って分割しない • 変更要求に対し、複数のサービスを横断して デプロイすることになる • 各サービスが⾃⾝でデータを所有する • データベースを共有しない • データはWeb APIやイベントなどで受け渡す 『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022

Slide 38

Slide 38 text

© 2023, Amazon Web Services, Inc. or its affiliates. ドメイン駆動設計 (DDD) とは • 高品質なソフトウェアモデルを設計 するためのソフトウェア開発手法 • ユビキタス言語 ー ビジネスドメイン エキスパートと開発者の間の意思疎通と して利用される用語によってモデリング と設計を行う • 戦略的な設計のためのガイドライン ー 境界づけられたコンテキスト、 蒸留、大規模な構造の考察 • 戦術的な設計 – 集約、エンティティ、 値オブジェクト、ドメインサービス 「エリック・エヴァンスのドメイン駆動設計」:エリック・エバンス著 2011/4/9 翔泳社 「実践ドメイン駆動設計」:ヴォーン・ヴァーノン著 2015/3/16 翔泳社

Slide 39

Slide 39 text

© 2023, Amazon Web Services, Inc. or its affiliates. 境界づけられたコンテキスト • 境界づけられたコンテキストは特定の • モデルを適⽤できる限定された範囲。 • コンテキストの境界を定めることで、 • チームメンバーは何を⼀致させるべきで 何を独⽴して開発できるのかについての 理解を明確化し、共有できる。 https://www.martinfowler.com/bliki/BoundedContext.html Customer Ticket Product Product version Customer Product Territory Opportunity Pipeline Salesperson Defect Sales context Support context

Slide 40

Slide 40 text

© 2023, Amazon Web Services, Inc. or its affiliates. コンテキストマップ Sales context Support context Marketing context 境界つけられたコンテキストだけでは、ドメインの 全体像を⽰すことはできない。 コンテキストマップは、境界づけられたコンテキスト を統合することにより、異なるが関連するユビキタス ⾔語のマッピングを処理する。 DDDでは境界づけられたコンテキストを統合するため の7つのパターンを説明 • 共有カーネル (Shared Kernel) • 顧客/供給者の開発チーム (Customer/Supplier Development Teams) • 順応者 (Conformist) • 腐敗防⽌層 (Anticorruption layer) • 別々の道 (Separate ways) • 公開ホストサービス (Open/Host service) • 公表された⾔語 (Published language)

Slide 41

Slide 41 text

© 2023, Amazon Web Services, Inc. or its affiliates. モデル駆動設計を構成する⾔語のナビゲーションマップ モデル駆動 設計 サービス エンティティ 値オブジェクト ファクトリ 集約 リポジトリ 利⼝なUI モデルを表現するのに使⽤する モデルを表現するのに使⽤する モデルを表現するのに使⽤する 排他的な選択 アクセスするのに使⽤する 整合性を保つのに 使⽤する アクセスするのに使⽤する ルートとして機能する カプセル化するのに使⽤する カプセル化するのに 使⽤する カプセル化するのに使⽤する カプセル化するのに使⽤する レイヤ化 アーキテクチャ ドメインを隔離する のに使⽤する

Slide 42

Slide 42 text

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. どうやって境界づけられたコンテキスト を定義するのか

Slide 43

Slide 43 text

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. ドメイン分割を導くのための Event Storming

Slide 44

Slide 44 text

© 2023, Amazon Web Services, Inc. or its affiliates. Event Stormingの概要 • ⾼品質なモデリングのための 簡単なワークショップ • ドメインエキスパートと開発者 が協⼒して実施 • 業務から、境界づけられた コンテキストとモデルを 導き出す

Slide 45

Slide 45 text

© 2023, Amazon Web Services, Inc. or its affiliates. Event Stormingの流れ - Big Picture • Eventの洗い出し、時系列化 • Pivotal Event (分割点になるEvent )をマーク • スイムレーン(並行処理、分岐点) の発見 • 関係者/外部システムを洗い出し • 上記完了後に、ナレーション/ ウォークスルー

Slide 46

Slide 46 text

© 2023, Amazon Web Services, Inc. or its affiliates. Event Stormingの流れ – Process Modeling • 洗い出したイベントをつなぎプロセスに § コマンド § ロール § リードモデル § ポリシー § システム § ホットスポット https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-with-eventstorming/27

Slide 47

Slide 47 text

© 2023, Amazon Web Services, Inc. or its affiliates. Event Stormingの流れ –Software Design • 集約を見つける、名前をつける • 境界づけられたコンテキストを見つける • 設計の詳細に入り、コーディングに進められるようにする

Slide 48

Slide 48 text

© 2023, Amazon Web Services, Inc. or its affiliates. 境界づけられたコンテキストとドメインモデル 在庫 オークション 支払い 台車 ピッカー 配送サービス 倉庫 商品 棚位置 サイズ 重さ 配送顧客 配送先 入札 落札 商品 SKU 画像 価格 入札顧客 ID 検索サービス 落札顧客 クレジットカード 支払い

Slide 49

Slide 49 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. データソースをサービスの所有ごとに分割 ⽀払い オークション 在庫 共有されている モノリシック データベース モノリシックシステム ⽀払い オークション 在庫 商品や顧客などもサービスによって利⽤する属性が 異なるので、それぞれのサービスの所有するデータ へ移⾏する。 データソースの移⾏計画も検討。 顧客マスタ 配送顧客 ⼊札顧客 ⽀払顧客

Slide 50

Slide 50 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 戦術的設計 • 集約、値オブジェクト、エンティティー • ドメインイベント 50

Slide 51

Slide 51 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 値オブジェクト • 構成要素の値によって識別されるオブジェクト • 識別⼦(ID)を必要としない • 例えば「⾊」値オブジェクト • イミュータブルで変更する 場合は全体を置き換え class Color { private _red:number; private _green:number; private _blue:number; constructor(red:number, green:number, blue:number){ this._red = red; this._green = green; this._blue = blue; } //...other methods }

Slide 52

Slide 52 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. エンティティ • 明確な識別⼦(ID)を必要とする • エンティティーはライフサイクルを持つ • エンティティーは更新可能 • 例えばPersonエンティティ class Person { private _id:string; private _name:string; constructor(id:string, name:string){ this._id = id; this._name = name; } //... }

Slide 53

Slide 53 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 集約 • 同⼀のトランザクション境界に属するエンティティと値オブジェクト の組み合わせ • 集約もエンティティなのでIDが必要 • 集約がトランザクションの単位 集約の ルート エンティティ 値オブジェクト エンティティ 1 0…* 1…* 1 ID

Slide 54

Slide 54 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 例 – オークションの集約 オークション 競売参加者 オークション品 1 * 1 ⽀払い⽅法 配送⽅法 * 1 1 1 54 集約ルート 在庫 1 1 競売⼈ 1 1 *

Slide 55

Slide 55 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 集約のルール • 集約はシンプルに⼩さく保つ • 集約の状態はパブリックインターフェイスでのみ変更可能 • 集約はトランザクション境界、集約の状態変更は アトミックな操作としてコミットする必要がある • 集約内のエンティティや値オブジェクトを表現する集約ルートを選択

Slide 56

Slide 56 text

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 集約の関連 • 他の集約への参照としてIDを利⽤ • 他の集約の更新はドメインイベントを利⽤した結果整合 境界づけられた コンテキスト 1 境界づけられた コンテキスト 2 ドメインイベント 集約 1 集約 2

Slide 57

Slide 57 text

© 2023, Amazon Web Services, Inc. or its affiliates. 作成したモデルをコードに反映 • 戦術的DDD § ドメインモデルを実装に反映する § モデルと実装は繰り返し改善する § ドメインモデルがビジネスロジックに対する責務を持つ § ドメインモデルとインフラストラクチャを分離する – 依存関係逆転の原則により、ドメイン層をシステム的な関⼼ごとから分離 – ヘキサゴナル/オニオン/クリーンアーキテクチャ

Slide 58

Slide 58 text

© 2023, Amazon Web Services, Inc. or its affiliates. 参考︓ヘキサゴナルアーキテクチャ Domain Model Ports Adapters Primary Actor Secondary Actor HTTP Request Event Message Queue … File Storage Database Queue …

Slide 59

Slide 59 text

© 2023, Amazon Web Services, Inc. or its affiliates. 参考︓ヘキサゴナルアーキテクチャ Domain Model Ports Adapters Primary Actor Secondary Actor HTTP Request Event Message Queue … File Storage Database Queue … アプリケーションはポートによって接続される アダプタは外界との糊の役⽬を果たす ドメインモデルはビジネスロジックを実⾏し、モデルの外側 についての知識を持たない

Slide 60

Slide 60 text

© 2023, Amazon Web Services, Inc. or its affiliates. 参考︓ヘキサゴナルアーキテクチャのサンプルコード • ヘキサゴナルアーキテクチャを利⽤したLambda関数のドメインモ デルの実装Live § 動画︓ https://www.youtube.com/watch?v=whQ-P05QeDQ § 資料︓ https://pages.awscloud.com/rs/112-TZM-766/images/DEV- 09_LiveCoding_with_hexagonal_architecture.pdf • ヘキサゴナルアーキテクチャを利⽤した AWS Lambda のドメイン モデルオブジェクトサンプルコード https://github.com/aws-samples/aws-lambda-domain- model-sample

Slide 61

Slide 61 text

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. まとめ

Slide 62

Slide 62 text

© 2023, Amazon Web Services, Inc. or its affiliates. まとめ • マイクロサービスは変化に素早く対応し、フィードバックを得て 改善を重ねるビジネスにマッチしている • マイクロサービスにはトレードオフがあり、マイクロサービスに 適した組織にする必要がある • マイクロサービスは機能や技術スタックによる分割ではなく ドメインによる分割を⾏う • ドメイン分割はドメイン駆動設計を活⽤する • ドメインエキスパートと開発者によるEvent Stormingによって 境界づけられたコンテキストとドメインモデルを定義し実装に反 映する