徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜 /why do you choose microservices architecture

JAWS UG 函館勉強会 Vol12

徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜

Transcript

1. © 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 〜マイクロサービスのメリット、デメリット、 なぜマイクロサービスを選択するのか〜
2. © 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 シリーズ
3. © 2023, Amazon Web Services, Inc. or its affiliates. Agenda • マイクロサービスとは • なぜマイクロサービスアーキテクチャを採⽤するのか • マイクロサービスに適した組織 • マイクロサービスのアンチパターン • どうやってサービスを分割するのか • ドメイン分割のためのEvent Storming • まとめ
4. © 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスとは
5. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスとは • ビジネスドメインに基づいて分割された、独⽴してデプロイ可能なサービス 映画情報 サービス 料⾦サービス 通知サービス 予約サービス 発送サービス 課⾦サービス 料⾦情報の 問い合わせ 上映⽇イベント 予約情報 問い合わせ
6. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスの重要な概念 『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022
7. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスの性質 疎結合で、独⽴性が⾼い • 独⽴してデプロイ可能 • つまり各サービスが疎結合 • ビジネスモデルの境界に沿って分割 • Web 三層 ⇔ ドメインモデル • 技術的な境界に沿って分割しない • 変更要求に対し、複数のサービスを横断して デプロイすることになる • 各サービスが⾃⾝でデータを所有する • データベースを共有しない • データはWeb APIやイベントなどで受け渡す 『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022
8. © 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. なぜマイクロサービスアーキテクチャ を採⽤するのか
9. © 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 レガシーが⾜かせ
10. © 2022, Amazon Web Services, Inc. or its Affiliates. 書店︖ タクシー︖ DVD︖ 業界の再定義 ホテル︖ 気分や⽬的に合わせた 宿泊体験 不安、⾯倒のない タクシー移動 いつでもどこでも 娯楽を提供 世界最⼤の 宿泊サービス提供 世界最⼤規模の配⾞事業 世界有数の エンターテイメント 世界最⼤規模の EC で 品揃え･低価格･利便性を提供 Amazon Account を使⽤し ⾳楽･映画等のサービス提供
11. © 2022, Amazon Web Services, Inc. or its Affiliates. 『 』 “…innovation is now recognized as the single most important ingredient in any modern economy…” イノベーション こそが近代経済において 最も重要な要素と考えられている。 競合よりも早く、新しい波を 創っていくことが重要
12. © 2022, Amazon Web Services, Inc. or its Affiliates. イノベーションがビジネスを進化させる 新たなマーケット 新たな顧客価値 New economics 新たなデジタル製品とサービス
13. © 2022, Amazon Web Services, Inc. or its Affiliates. Listen Idea Experiment Innovation Flywheel 実験がイノベーションを加速する
14. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスに変更する理由 チームの⾃律性 チームの規模が⼩さくなることでコミュニケーションコストが減る ⾃⾝のサービスを完全にコントロールでき、⾃律的⾃発的な機能改善に繋がる アジリティ 各機能を他の機能のリリースを調整せずにリリースできるようになる スケーリング 負荷が⾼い機能のみをスケーリングすることができる 堅牢性 負荷が⾼まったとき、リリースによる障害などの影響が単⼀のサービスにとどまり、アプリケー ション全体としての堅牢性が⾼まる 採⽤技術の柔軟性 各サービス毎に異なる⾔語やアーキテクチャ(VM/コンテナ/サーバーレス/etc)を採⽤できる
15. © 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. マイクロサービスに適した組織
16. © 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 • すべてを所有
17. © 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.
18. © 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
19. © 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark コンポーネントの分割 原則 • 可能な限り⼩さなユニットにする（プリミティブ） • データドメインの作成 • 関数単位ではなくスケールファクタによる分割 • 個々のサービスは独⽴して運⽤ 組織間の連携による待ち時間の発⽣を抑える • サービス間はAPI（契約）で連携 これにより組織の変更が導かれました
20. © 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 • サービスを所有 • 制約を最⼩化 （コンウェイの法則） • 意思決定のための⾃⽴した組織
21. © 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 組織の再編成の開始 ひとつのチームでどうやって実⾏するのか? すべてを所有 • 計画 • セキュリティ • パフォーマンス • スケーラビリティ • デプロイメント • 運⽤ • バグ • ⽂書化 • テスト…
22. © 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
23. © 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark スクラムロール例 スクラムマスター、開発者、プロダクトオーナー チームにアジャイルな⽅法論を適⽤ スクラムボード例
24. © 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark 組織内の “サイロ” 化が勢いを無くす要因 オペレーション データベース チーム 品質保証 アプリケーション セキュリティ ソフトウェア 開発チーム “開発環境のセットアップを 待機するため作業を中断" “新しいテーブルや SQL スクリプトを 待機するため作業を中断" “パフォーマンステストを 待機するために作業を中断" “ ソースコードの⼿動検査を 待機するため作業を中断 " “データベースセキュリティの承認待機するため作業を中断" “セキュリティテストの完了を 待機するため作業を中断" “セキュリティ証明書の作成を 待機するため作業を中断" “データベースホストのセットアップを 待機するため作業を中断" “新しいテストのホストを待機するために作業を中断 ”
25. © 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark マイクロサービスはDevOpsのスタイルで運⽤すべき オペレーション データベー ス管理者 品質保証 (テスト担当者) アプリケーション セキュリティ ソフトウェア開発 チーム “共働"
26. © 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスのトレードオフ
27. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスのトレードオフ 分散システムに伴う複雑性 ネットワーク呼出による連携となり、モノリシックシステムでメ ソッドを呼び出すときには発⽣しなかった考慮点が発⽣する ネットワークのエラーや遅延、呼出先のダウン、障害発⽣時のトラ ブルシューティングなど 整合性の担保 モノリシックなシステムではトランザクションで容易に強⼒な整合 性を担保できる マイクロサービスで同様の整合性は担保できない マイクロサービスの統廃合やリファクタリングが困難 モノリスではIDEの機能で⾃動的にインターフェースやクラスの分割、 抽出、統合が可能で、データスキーマも整理可能 マイクロサービスでは、そのような統廃合は複数のサービスチーム の調整やデータの移管が必要
28. © 2023, Amazon Web Services, Inc. or its affiliates. トレードオフの対策 分散システムに伴う複雑性 ⾮同期なイベント駆動で連携したり、同期API呼出の場合はサー ビスメッシュを利⽤する 整合性の担保 整合性が必要な単位でマイクロサービスを分割しない どこで整合性が必要なのか、ビジネスのモデリングが必要 サーガパターンなど、結果整合性を担保するデザインパターンを 利⽤する マイクロサービスの統廃合やリファクタリングが困難 統廃合がなるべく発⽣しないよう、ビジネスのモデリングが必要
29. © 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスのアンチパターン
30. © 2023, Amazon Web Services, Inc. or its affiliates. チーム内に意思決定する権限がない • ビジネス的な価値を提供するために、どの機能を優先的にリリー スするかをチームで決定できない • ユーザーからのフィードバックを受けて何をどのように改善する かを決定できない • チームが自律的に行動できる組織になっていない
31. © 2023, Amazon Web Services, Inc. or its affiliates. 開発メンバーの数がサービスより少ない • 開発者3人で20以上のマイクロサービスを開発しているなど • 開発者がボトルネックとなってリリースや改善の頻度が低下
32. © 2023, Amazon Web Services, Inc. or its affiliates. バックエンドのデータベースを各サービスで共有 • マイクロサービスではない • 密結合になっておりマイクロサービスのメリットが活かせない
33. © 2023, Amazon Web Services, Inc. or its affiliates. サービス単位ではなく機能単位のチーム構成している • UI、アプリケーション、データベース など機能単位にチームが分かれている 「マイクロサービスアーキテクチャ 第2版」オライリージャパン 2022
34. © 2023, Amazon Web Services, Inc. or its affiliates. ドメインをまたがって密結合になっている • ビジネスドメインの境界に従ってサービスが分割されていない • 境界づけられたコンテキスト間はドメインイベントで疎結合にする • 分散システムでは、非同期、結果整合を許容する必要がある
35. © 2023, Amazon Web Services, Inc. or its affiliates. 明確な目的もなくマイクロサービスを選択している • 銀の弾丸ではない • 「流行っているから」「新しい手法だから」という理由でマイクロ サービスアーキテクチャを選択しない • マイクロサービスのもたらす価値と複雑性のトレードオフを考慮
36. © 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. どうやってサービスを分割するのか
37. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービスの性質（再掲） 疎結合で、独⽴性が⾼い • 独⽴してデプロイ可能 • つまり各サービスが疎結合 • ビジネスモデルの境界に沿って分割 • Web 三層 ⇔ ドメインモデル • 技術的な境界に沿って分割しない • 変更要求に対し、複数のサービスを横断して デプロイすることになる • 各サービスが⾃⾝でデータを所有する • データベースを共有しない • データはWeb APIやイベントなどで受け渡す 『マイクロサービスアーキテクチャ第2班』オライリー・ジャパン、2022
38. © 2023, Amazon Web Services, Inc. or its affiliates. ドメイン駆動設計 (DDD) とは • 高品質なソフトウェアモデルを設計 するためのソフトウェア開発手法 • ユビキタス言語 ー ビジネスドメイン エキスパートと開発者の間の意思疎通と して利用される用語によってモデリング と設計を行う • 戦略的な設計のためのガイドライン ー 境界づけられたコンテキスト、 蒸留、大規模な構造の考察 • 戦術的な設計 – 集約、エンティティ、 値オブジェクト、ドメインサービス 「エリック・エヴァンスのドメイン駆動設計」：エリック・エバンス著 2011/4/9 翔泳社 「実践ドメイン駆動設計」：ヴォーン・ヴァーノン著 2015/3/16 翔泳社
39. © 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
40. © 2023, Amazon Web Services, Inc. or its affiliates. コンテキストマップ Sales context Support context Marketing context 境界つけられたコンテキストだけでは、ドメインの 全体像を⽰すことはできない。 コンテキストマップは、境界づけられたコンテキスト を統合することにより、異なるが関連するユビキタス ⾔語のマッピングを処理する。 DDDでは境界づけられたコンテキストを統合するため の７つのパターンを説明 • 共有カーネル (Shared Kernel) • 顧客/供給者の開発チーム (Customer/Supplier Development Teams) • 順応者 (Conformist) • 腐敗防⽌層 (Anticorruption layer) • 別々の道 (Separate ways) • 公開ホストサービス (Open/Host service) • 公表された⾔語 (Published language)
41. © 2023, Amazon Web Services, Inc. or its affiliates. モデル駆動設計を構成する⾔語のナビゲーションマップ モデル駆動 設計 サービス エンティティ 値オブジェクト ファクトリ 集約 リポジトリ 利⼝なUI モデルを表現するのに使⽤する モデルを表現するのに使⽤する モデルを表現するのに使⽤する 排他的な選択 アクセスするのに使⽤する 整合性を保つのに 使⽤する アクセスするのに使⽤する ルートとして機能する カプセル化するのに使⽤する カプセル化するのに 使⽤する カプセル化するのに使⽤する カプセル化するのに使⽤する レイヤ化 アーキテクチャ ドメインを隔離する のに使⽤する
42. © 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. どうやって境界づけられたコンテキスト を定義するのか
43. © 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. ドメイン分割を導くのための Event Storming
44. © 2023, Amazon Web Services, Inc. or its affiliates. Event Stormingの概要 • ⾼品質なモデリングのための 簡単なワークショップ • ドメインエキスパートと開発者 が協⼒して実施 • 業務から、境界づけられた コンテキストとモデルを 導き出す
45. © 2023, Amazon Web Services, Inc. or its affiliates. Event Stormingの流れ - Big Picture • Eventの洗い出し、時系列化 • Pivotal Event (分割点になるEvent )をマーク • スイムレーン(並行処理、分岐点) の発見 • 関係者/外部システムを洗い出し • 上記完了後に、ナレーション/ ウォークスルー
46. © 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
47. © 2023, Amazon Web Services, Inc. or its affiliates. Event Stormingの流れ –Software Design • 集約を見つける、名前をつける • 境界づけられたコンテキストを見つける • 設計の詳細に入り、コーディングに進められるようにする
48. © 2023, Amazon Web Services, Inc. or its affiliates. 境界づけられたコンテキストとドメインモデル 在庫 オークション 支払い 台車 ピッカー 配送サービス 倉庫 商品 棚位置 サイズ 重さ 配送顧客 配送先 入札 落札 商品 SKU 画像 価格 入札顧客 ID 検索サービス 落札顧客 クレジットカード 支払い
49. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. データソースをサービスの所有ごとに分割 ⽀払い オークション 在庫 共有されている モノリシック データベース モノリシックシステム ⽀払い オークション 在庫 商品や顧客などもサービスによって利⽤する属性が 異なるので、それぞれのサービスの所有するデータ へ移⾏する。 データソースの移⾏計画も検討。 顧客マスタ 配送顧客 ⼊札顧客 ⽀払顧客
50. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 戦術的設計 • 集約、値オブジェクト、エンティティー • ドメインイベント 50
51. © 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 }
52. © 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; } //... }
53. © 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
54. © 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 *
55. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 集約のルール • 集約はシンプルに⼩さく保つ • 集約の状態はパブリックインターフェイスでのみ変更可能 • 集約はトランザクション境界、集約の状態変更は アトミックな操作としてコミットする必要がある • 集約内のエンティティや値オブジェクトを表現する集約ルートを選択
56. © 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
57. © 2023, Amazon Web Services, Inc. or its affiliates. 作成したモデルをコードに反映 • 戦術的DDD § ドメインモデルを実装に反映する § モデルと実装は繰り返し改善する § ドメインモデルがビジネスロジックに対する責務を持つ § ドメインモデルとインフラストラクチャを分離する – 依存関係逆転の原則により、ドメイン層をシステム的な関⼼ごとから分離 – ヘキサゴナル/オニオン/クリーンアーキテクチャ
58. © 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 …
59. © 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 … アプリケーションはポートによって接続される アダプタは外界との糊の役⽬を果たす ドメインモデルはビジネスロジックを実⾏し、モデルの外側 についての知識を持たない
60. © 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
61. © 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. まとめ
62. © 2023, Amazon Web Services, Inc. or its affiliates. まとめ • マイクロサービスは変化に素早く対応し、フィードバックを得て 改善を重ねるビジネスにマッチしている • マイクロサービスにはトレードオフがあり、マイクロサービスに 適した組織にする必要がある • マイクロサービスは機能や技術スタックによる分割ではなく ドメインによる分割を⾏う • ドメイン分割はドメイン駆動設計を活⽤する • ドメインエキスパートと開発者によるEvent Stormingによって 境界づけられたコンテキストとドメインモデルを定義し実装に反 映する