マイクロサービス設計に活⽤する DDDとEvent Storming / designing_microservices_with_DDD_and_EventStorming

マイクロサービス設計に活用する DDDとEVENT STORMING © 2023, Amazon Web Services, Inc. or
its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. マイクロサービス設計に活⽤する DDDとEvent Storming マイクロサービス化を選択する際の考慮点 Atsushi Fukui Senior Solutions Architect, Developer Specialist Amazon Web Services Japan

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

its affiliates. Agenda • マイクロサービスとは • なぜマイクロサービスアーキテクチャを採⽤するのか • Amazonが学んだこと • マイクロサービスのトレードオフ • どうやってサービスを分割するのか • ドメイン分割のためのEvent Storming • まとめ

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

its affiliates. マイクロサービスの性質疎結合で、独⽴性が⾼い • 独⽴してデプロイ可能 • つまり各サービスが疎結合 • ビジネスモデルの境界に沿って分割 • Web 三層 ⇔ ドメインモデル • 技術的な境界に沿って分割しない • 変更要求に対し、複数のサービスを横断してデプロイすることになる • 各サービスが⾃⾝でデータを所有する • データベースを共有しない • データはWeb APIやイベントなどで受け渡す Sam Newman. モノリスからマイクロサービスへ

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

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

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

its affiliates. Listen Idea Experiment Innovation Flywheel 実験がイノベーションを加速する

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

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

its affiliates. マイクロサービスが良い選択肢ではない場合 • ドメインが不明確 • サービスの境界を間違えるとコストがかかる可能性 • スタートアップ • マイクロサービスの複雑性が却って⾜枷に • COTS(市販品)ソフトウェア • 正当な理由がない • 「流⾏っているから」「他がやっているから」で始めるのは危険

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

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

its affiliates. マイクロサービスの性質（再掲）疎結合で、独⽴性が⾼い • 独⽴してデプロイ可能 • つまり各サービスが疎結合 • ビジネスモデルの境界に沿って分割 • Web 三層 ⇔ ドメインモデル • 技術的な境界に沿って分割しない • 変更要求に対し、複数のサービスを横断してデプロイすることになる • 各サービスが⾃⾝でデータを所有する • データベースを共有しない • データはWeb APIやイベントなどで受け渡す Sam Newman. モノリスからマイクロサービスへ

its affiliates. ドメイン駆動設計 (Domain Driven Design, DDD) とは • ⾼品質なソフトウェアモデルを設計するためのソフトウェア開発⼿法 • 設計における意思決定とドメイン設計の議論における技術的な⽤語の広義のフレームワークを提供 • ユビキタス⾔語ービジネスドメインエキスパートと開発者の間の意思疎通として利⽤される⽤語によってモデリングと設計を⾏う • 戦略的な設計のためのガイドラインー境界づけられたコンテキスト、蒸留、⼤規模な構造の考察

its affiliates. ドメイン駆動設計（DDD）とは「DDDには戦略的モデリングと戦術的モデリングの両⽅のためのツールが⽤意されており、業務要件を満たす⾼品質なソフトウェアを設計するために、必要に応じて使える。」ヴァーン・ヴァーノン. 実践ドメイン駆動設計 (Japanese Edition) (Kindle Locations 744-746). Kindle Edition.

its affiliates. AWS Developer Live Show - 「ドメイン駆動設計のススメ」 24 https://go.aws/3Q2nNgl

its affiliates. 戦略的DDD 26 • 業務をモデリングする設計理論業務業務モデル予約航路旅程ユーザーモデリング • ユビキタス言語 • 境界づけられたコンテキスト • コンテキストマップ • ドメインビジョン • コアドメイン • 汎用サブドメイン • etc ..

its affiliates. 戦術的DDD 27 • モデリングされた業務をシステムに落とす • ユビキタス言語 • リポジトリ • 依存関係の逆転 • サービス • 値オブジェクト • エンティティ • ファクトリ • 集約業務モデル予約航路旅程ユーザー反映システム

its affiliates. 脆いシステムになる代表的な原因 29 • 言語の壁 • 不明瞭なコンテキスト業務モデル予約航路旅程ユーザー

its affiliates. モデリングを阻む⾔語の壁 30 if (code == 5) { person.setCode(6); } else if (sCode == 7) { system.set(CODE_9); } else if (sCode == 12) { new MySQL().insert("ERROR values (type1, 5)"); System.exit(); } 業務内部仕様書これで合ってる？？？？開発者

its affiliates. モデルという共通⾔語でコミュニケーション 31 業務業務モデル予約航路旅程ユーザーモデリング if (route.enable(time)) { return new Reservation(user, route, time); } else { return new FalseReservation("the route cannot be used for the time"); } 反映合ってそう / 違和感があるこれで合ってる？？開発者ドメインエキスパート

its affiliates. ユビキタス⾔語 32 • 業務モデルで使⽤される、業務側も開発側も理解できる共通⾔語 • システムに関わる全ての場所で⼀貫してユビキタス⾔語が使われるべき • モデル、コード、仕様書、ドキュメント、etc.. • 共通⾔語がないと脆いシステムになりやすい • 業務モデルで利⽤されるチームで作り上げられた共通⾔語業務モデル予約航路旅程ユーザードメインエキスパート開発者業務 if (route.enable(time)) { return new Reservation(user, route, time); } else { return new FalseReservation("the route cannot be used for the time"); }

its affiliates. 戦略的設計 • ビジネスドメインを理解する • 境界づけられたコンテキストからサブドメインを定義する • コンテキストマッピングを定義する

its affiliates. ビジネスドメインの理解境界づけられたコンテキストユビキタス言語コンテキストの外側ドメインエキスパート

its affiliates. 境界づけられたコンテキストでサブドメインに分割 “ビジネスドメイン全体の中の⼀部分” オークションユーザー認証支払い配送在庫通知オークションビジネスドメイン

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

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)

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

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

its affiliates. Event Stormingの概要 44 ⾼品質なモデリングのための簡単なワークショップ（ワイワイやる感じの）業務から、境界づけられたコンテキストとモデルを導き出す

its affiliates. Event Storming は以下のステップを繰り返す • Big Picture • Process Modeling • Software Design

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

its affiliates. Step1 - ドメインイベントの洗い出し

its affiliates. Step2 - 時系列に並べ替え

its affiliates. Step3 - Pivotal Eventをマーク

its affiliates. Step4 - スイムレーンの洗い出し

its affiliates. Step5 - 関係者、外部システムの洗い出し ....

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

its affiliates. Step6 - コマンドの追加 ....

its affiliates. Step7 - アクターとポリシーの洗い出し ....

its affiliates. Step8 - リードモデルの追加 ....

its affiliates. Event Stormingの流れ –Software Design • 集約を⾒つける、名前をつける • 境界づけられたコンテキストを⾒つける • 設計の詳細に⼊り、コーディングに進められるようにする

its affiliates. Step9 - 集約を⾒つける

its affiliates. Step10 – 境界づけられたコンテキストを⾒つける ....

its affiliates. 戦術的設計 60 • 集約、値オブジェクト、エンティティー • ドメインイベント

its affiliates. 値オブジェクト • 構成要素の値によって識別されるオブジェクト • 識別⼦（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 }

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

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

its affiliates. 例 – オークションの集約 64 オークション競売参加者オークション品 1 * 1 支払い方法配送方法 * 1 1 1 集約ルート在庫 1 1 競売人 1 1 *

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

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

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

its affiliates. イベント駆動アーキテクチャの利⽤ • イベント駆動アーキテクチャについては、以下のシリーズを参照 • AWS DevAx::Connect シーズン１「イベント駆動」 • https://aws.amazon.com/jp/devax-connect-on-demand/

its affiliates. ドメインモデル DDD-Event Storming AWS サービス Well-Architected の原則概念モデル論理モデル物理モデル現在の課題技術的な課題非機能要件システムデザインパターンベストプラクティス境界づけられたコンテキストコンテキストマップ集約論理アーキテクチャシステムコンポーネントドメインコンポーネントシステム構成要素物理アーキテクチャ AWSサービス上の意思決定アーキテクチャの意思決定を記録ネットワークゾーンデプロイメント単位ノード機能説明ドメインモデルから物理アーキテクチャへ

its affiliates. 論理アーキテクチャへのマッピング品質特性非機能要件論理アーキテクチャ性能効率性スケーラビリティーの担保、スロットリング要件など（例）ピーク時 1,000リクエスト/秒のリクエスト APIゲートウェイコンポーネントセキュリティー IDプロバイダの要件、認可要件など。（例）認証されたリクエストのみが認可された権限範囲でAPIにアクセス可能認証プロバイダコンポーネント信頼性可能性の要件、サービスの稼働率など。（例）疎結合な連携で一部のAZで障害が発生してもサービスを継続メッセージキューコンポーネント保守性障害発生の検知など（例）サービスにまたがるモニタリング、ロギング集約ログコンポーネント、可視化コンポーネント ... ... ...

its affiliates. 参考︓ソフトウェア品質モデル ISO/IEC 25010:2011（JISX 25010: 2013）ソフトウェアの品質モデル「JIS X 25010：2013 システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル」より

its affiliates. 論理アーキテクチャから物理アーキテクチャへ • アーキテクチャの意思決定を記録する § なぜそのアーキテクチャを選択したのか • 付加価値を⽣まない重労働をクラウドのサービスにオフロードする § サーバーレスやマネージドサービスを活⽤ • デプロイメント単位を決定し頻繁にリリース可能にする § CI/CDによる⾃動化 • ⽇々の運⽤で知⾒を蓄え可観測性を⾼める § トレース、ログ、メトリクス、アラートの設定

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

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

its affiliates. サンプルアーキテクチャ AWS Cloud Amazon API Gateway AWS Lambda Amazon DynamoDB User Internet

its affiliates. ドメインモデル、ポート、アダプターの構成 API Gateway Lambda関数ドメインモデル Lambdaサービスアダプターアプリケーションサービス（ポート）アプリケーションサービス（ポート）アダプターアダプターアダプターデータソースの呼び出し

its affiliates. ドメインモデルクラス import { AuctionItem } from "./auction_item"; export class Auction { private auction_id: number; private auction_name: string; private auction_items: AuctionItem[]; // .... more members constructor(name: string, ...) { this.auction_name = name; //...initializing code } addAuctionItem(item: AuctionItem) { this.auction_items.push(item); //...more code } ドメインモデルで定義されたピュアなビジネスロジックのみが実装される。外部の世界に対する知識を持たない。

its affiliates. ポートクラス（アプリケーションサービス） import { Auction } from "./auction"; import { AuctionItem } from "./auction_item"; import { IAuctionAdapter } from "./i_auction_adapter"; import { IAuctionController } from "./i_auction_controller"; export class AuctionController implements IAuctionController { private auction: Auction; private auction_adapter: IAuctionAdapter; //... constructor(auction: Auction, auction_adapter: IAuctionAdapter) { this.auction = auction; this.auction_adapter = auction_adapter; //... } add_auction_items(items: AuctionItem[]) { //... ポートクラスがドメインモデルとアダプターのインスタンスを受け取り、ドメインモデルとアダプターを呼び出す。

its affiliates. アダプタクラス import { Auction } from "./auction"; import { IAuctionAdapter } from "./i_auction_adapter"; export class AuctionAdapter implements IAuctionAdapter { store_auction(auction: Auction) { //ドメインモデルの永続化 //... } } アダプタークラスは外部サービスとの連携を担当単体テスト時はダミークラスに差し替えてテストを実行

its affiliates. 依存関係 <Domain Model> Auction <Port> AuctionController <Adapter> AuctionDBAdapter <interface> IAuctionAdapter <Adapter> DummyAdapter

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

its affiliates. ビッグバンでの移⾏はお勧めしません︕ 終わりが見えない。。。今から丸3年かけて 2026年9月にマイクロサービス化した新システムをリリースするぞー！会社の偉い人現場の担当者

its affiliates. ビジネスドメインに従ってサービスを分割しストラングラーパターンで徐々に移⾏ • ストラングラーパターン • レガシーアプリケーションのさまざまなコンポーネントのイベントと API を徐々に作成して、モノリシックアプリケーションをマイクロサービスに移行する

its affiliates. アカウントサービスユーザーサービスカートサービス Store Front ユーザーインターフェイス直接カットオーバーせず、ストラングラーパターンを使⽤してリスクを軽減ストラングラーパターンでモノリスから移⾏共有されているモノリシックデータベースレガシーシステムブラウザ

its affiliates. アカウントサービスユーザーサービスカートサービス共有されているモノリシックデータベース Store Front ユーザーインターフェイス新機能サービスレガシーシステムブラウザ API ストラングラーパターンでモノリスから移⾏

its affiliates. アカウントサービスユーザーサービスカートサービス共有されているモノリシックデータベース Store Front ユーザーインターフェイスユーザーマイクロサービス ACL(Anti-corruption layer) は、境界づけられたコンテキスト間で通信するための手段として使用される。 ACLが1 つのコンテキストから別のコンテキストへ翻訳するので、各コンテキストのモデルは独立を保ち自身の言葉づかいを反映することができる ACL レガシーシステムブラウザ新機能サービス API ストラングラーパターンでモノリスから移⾏

its affiliates. アカウントサービスユーザーサービスカートサービス共有されているモノリシックデータベース Store Front ユーザーインターフェイスレガシーシステムクライアントブラウザユーザーマイクロサービス新機能サービス API API ストラングラーパターンでモノリスから移⾏

its affiliates. アカウントサービスユーザーサービスカートサービス共有されているモノリシックデータベース Store Front ユーザーインターフェイスレガシーシステムクライアントブラウザサービスがSSoT(※)になる ※Single Source of Truth ユーザーマイクロサービス新機能サービス API API ストラングラーパターンでモノリスから移⾏

its affiliates. アカウントサービスユーザーサービスカートサービス共有されているモノリシックデータベース Store Front ユーザーインターフェイスレガシーシステムクライアントブラウザキュー/エージェントを使⽤して同期ユーザーマイクロサービス新機能サービス API API ストラングラーパターンでモノリスから移⾏

its affiliates. アカウントサービスユーザーサービスカートサービス共有されているモノリシックデータベース Store Front ユーザーインターフェイスレガシーシステムクライアントブラウザカートマイクロサービス ACL ユーザーマイクロサービス新機能サービス API API API ストラングラーパターンでモノリスから移⾏

its affiliates. アカウントサービスユーザーサービス共有されているモノリシックデータベース Store Front ユーザーインターフェイスレガシーシステムクライアントブラウザカートマイクロサービス ACL ユーザーマイクロサービス新機能サービス API API API アカウントマイクロサービス API ストラングラーパターンでモノリスから移⾏

its affiliates. Store Front ユーザーインターフェイスブラウザカートマイクロサービスユーザーマイクロサービス新機能サービス API API API アカウントマイクロサービス API ストラングラーパターンでモノリスから移⾏

its affiliates. AWS Migration Hub リファクタリングスペースリファクタリング環境の設定と管理にかかる時間を短縮 AWS Migration Hub リファクタリングスペースアプリの利⽤者をインフラの変更から保護複数の AWS アカウント間でトラフィックを旧→新に再ルーティングするアプリケーションのリファクタリングを数か⽉ではなく数⽇で開始する

its affiliates. • Leave and layer 別の出発点を提供 • 古いアプリケーションに触れることなく、マイクロサービスの新機能でアプリを強化、または拡張する • 新しい機能をlaunchするか、最⼩限のリスクで迅速にビジネスを拡⼤する Strangler Fig は、チームの独⽴性と最新のアプリアーキテクチャを実現するのに役⽴つ • リファクタリングする最初の部分とのインターフェースを定義する • 新しい機能を設計、実装、テストする • 古いものから新しいものにリダイレクト • 古いコードまたはサービスを停⽌する段階的にリファクタリングする新機能をすばやくlaunchするアプリ変換のための複数のリファクタリングパターン

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

マイクロサービス設計に活⽤する DDDとEvent Storming / designing_...

マイクロサービス設計に活⽤する DDDとEvent Storming / designing_microservices_with_DDD_and_EventStorming

More Decks by Atsushi Fukui

Other Decks in Technology

Featured

Transcript