Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Learning Domain-Driven Design輪読会#16

kyotak
November 17, 2022
20

Learning Domain-Driven Design輪読会#16

kyotak

November 17, 2022
Tweet

Transcript

  1. Learning Domain-Driven Design
 輪読会 #16
 株式会社Showcase Gig 
 中島 清貴

    (@ahyataro) 
 #lddd_rindoku
 Chapter 14. Microservices 

  2. 本資料は書籍「Learning Domain-Driven Design」のChapter14を意訳・要約したもので す。
 資料に記載の内容は @ahyataro が解釈した 内容であり、原文の表現や内容と異なるもの も含まれています
 注意


  3. OverView
 Chapter 14. Microservices
 • What Is a Service? /

    サービスとは?
 • What Is a Microservice? / マイクロサービスとは?
 • Domain-Driven Design and Microservices’ Boundaries/ ドメイン駆動設計とマ イクロサービスの境界
 • Compressing Microservices’ Public Interfaces / 包括的なマイクロサービスの パブリックインターフェース
 • Conclusion / 結論
 • Exercises / エクササイズ

  4. Microservices
 • 2010年代半ば、マイクロサービスはソフトウェアエンジニアリング業界を席巻し た
 • その目的は、素早く変化、拡張するモダンシステムのニーズに対応し、クラウド コンピューティングの分散性に自然に適合することだった
 • 多くの企業は、マイクロサービスベースのアーキテクチャによって提供される柔 軟性を優先して、モノリシックコードベースを分解するという戦略的決定を下した

    が、残念ながらその努力の多くはうまくいかなかった
 • 柔軟なアーキテクチャの代わりに、モノリスよりもはるかに壊れやすく、塊状で、 高価な設計である、分散した大きな泥だんごになってしまった
 

  5. Microservices
 
 • マイクロサービスはDDD、特に境界づけられたコンテクストパターンに関連付けら れることがよくある
 • 多くの人は境界づけられたコンテクストとマイクロサービスを同じ意味で使用して いるが、それは本当に同じものだろうか?
 • この章では、ドメイン駆動設計とマイクロサービスのアーキテクチャパターンの関

    係と、DDDを活用して効果的なマイクロサービスベースのシステムを設計する方 法を学習する
 

  6. 14-1. What Is a Service? / サービスとは?

  7. What Is a Service? • OASISによると、サービスとは1つ以上の機能へのアクセスを可能にするメカ ニズムであり、アクセスは規定のインターフェースを使用して提供される
 • 規定のインターフェースはサービスにデータを入れたり、サービスからデータ を取得したりするためのメカニズム


    • 他のシステムコンポーネントと通信および統合する手段を提供するパブリッ クインターフェースである

  8. What Is a Service?
 • Randy Shoupは、サービスのインターフェー スを正面玄関に例えている
 • サービスに出入りする全てのデータは、正面

    玄関を通過する必要がある
 • サービスのパブリックインターフェースは サービス自体を定義する
 • 適切に表現されたインターフェースはサービ スによって実装される機能を十分に記述す る

  9. 14-2. What Is a Microservice? / マイクロサービスとは?

  10. What Is a Microservice?
 • マイクロサービスはマイクロパブリックインターフェースを持つサービス
 • マイクロパブリックインターフェースを使用すると、単一のサービスの機能と他の システムコンポーネントとの統合の両方を理解しやすくなる
 •

    サービスの機能を減らすと、変更の理由も制限され、開発、管理、スケーリング に対してサービスがより自律的になる
 • マイクロサービスはデータベースを公開しない
 • データベースを公開し、サービスのフロントドアの一部にすると、そのパブリック インターフェースは巨大になる(SQLは無数のクエリを発行できるため)
 • したがって、マイクロサービスはデータベースをカプセル化する

  11. What Is a Microservice?
 • マイクロサービスがマイクロパブリックインターフェースであるというのは、一見単純で ある
 • サービスインターフェースを1つのメソッドに制限すると完全なマイクロサービスを得ら れるように聞こえるかもしれない


    • この素朴な分解を実際に適用すると以下のようになる
 Method as a Service: Perfect Microservice?

  12. What Is a Microservice?
 • パブリックインターフェースは8つのパブリックメソッドで構成されており、「サービス ごとに1つのメソッド」ルールが適用されている
 • それぞれのサービスはデータベースをカプセル化する
 •

    別のサービスのデータベースに直接アクセスすることはできず、パブリックインター フェースを介すことしかできない
 • しかし、そのためのパブリックインターフェースはない

  13. What Is a Microservice?
 • サービスは連携して動作し、各サー ビスが適用している変更を同期する 必要がある
 • その結果、これらの統合関連の懸念

    に対応するために、サービスのイン ターフェースを拡張する必要がある
 • サービス間の統合とデータフローは 右図のように典型的な分散された大 きな泥だんごになる

  14. What Is a Microservice?
 • システムをこのようなきめ細かなサービスに分解することで、サービスのフロント ドアを最小限に抑えたと言える
 • ただし包括的なシステムの機能を実装するには、各サービスに膨大な「スタッフ のみ」の入り口を追加する必要になった


    • このことから、各サービスに1つのメソッドのみを公開させるという単純な分解 ヒューリスティックは多くの理由で最適でないことが判明した
 ◦ サービスは連携する必要があるので、統合関連のパブリックメソッドを使用 してパブリックインターフェースを拡張することを余儀なくされた
 ◦ 各サービスは元の設計よりもはるかに単純にはなったが、全体のシステム は桁違いに複雑になってしまった

  15. What Is a Microservice?
 • マイクロサービスアーキテクチャの目標は柔軟なシステムを作ること
 • 設計作業を単一のコンポーネントに集中させ、システムの他の部分との相互作 用を無視することは、システムの定義そのものに反する
 •

    独立したコンポーネントからシステムを構築することはできない
 • 適切なマイクロサービスベースのシステムでは、たとえ分離されていてもサービ スを統合して相互に通信する必要がある
 • 個々のマイクロサービスの複雑さと包括的なシステムの複雑さの相互作用を見 ていこう
 Design Goal

  16. What Is a Microservice?
 • 40年前はクラウドコンピューティングはなく、グローバル規模の要件もなく、11.7 秒ごとにシステムを展開する必要もなかった
 • しかし、エンジニアは依然としてシステムの複雑さを抑える必要があった
 System

    Complexity

  17. What Is a Microservice?
 Glenford J. Myersは、著書「Composite/Structured Design」で手続き型コードを構造 化して複雑さを軽減する方法について論じている
 There

    is much more to the subject of complexity than simply attempting to minimize the local complexity of each part of a program. A much more important type of complexity is global complexity: the complexity of the overall structure of a program or system (i.e., the degree of association or interdependence among the major pieces of a program). 複雑さの主題には、プログラムの各部分の局所的な複雑さを単に最小限に抑えようとす るよりはるかに多くのことがある。複雑さのはるかに重要なタイプは、グローバルな複雑 さ、つまりプログラムまたはシステムの全体的な構造の複雑さ(つまり、プログラムの主要 な部分間の関連性または相互依存の程度)である

  18. What Is a Microservice?
 • ローカルの複雑さは個々のマイクロサービスの複雑さであり、グローバルな複 雑さはシステム全体の複雑さである
 • ローカルの複雑さはサービスの実装によって異なる
 •

    グローバルな複雑さは、サービス間の相互作用と依存関係によって定義される
 • マイクロサービスベースのシステムを設計する際に最適化することがより重要な 複雑さはどちらだろうか?

  19. What Is a Microservice?
 • グローバルな複雑さを最小限に抑えるのは簡単
 • 必要なのは、システムのコンポーネント間の相互作用を排除すること、つまり全 ての機能を1つのモノリシックサービスに実装することだけ
 •

    この戦略は特定のシナリオで機能する可能性はあるが、恐ろしい大きな泥だん ごに繋がる可能性もある
 • 一方で局所的な複雑さのみを最適化し、システムのグローバルな複雑さ、つま りさらに恐ろしい分散された大きな泥だんごを無視するとどうなるかもわかって いる

  20. What Is a Microservice?
 • 適切なマイクロサービスベースのシステ ムを設計するには、グローバルとローカ ルの両方の複雑さを最適化する必要が ある
 •

    どちらかを個別に最適化するという設計 目標を設定することは局所最適である

  21. What Is a Microservice?
 • ソフトウェアシステムまたは任意のモジュールはその機能とロジックによって定 義される
 • 関数はモジュールが行うことになっていること、つまりそのビジネス機能である
 •

    ロジックはモジュールのビジネスロジックであり、モジュールがビジネス機能を実 現する方法である
 • John Ousterhoutは、著書「The Philosophy of Software Design」でモジュール性 の概念について議論し、モジュールの設計を評価するためのシンプルでありな がら強力な視覚的ヒューリスティックである深さを提案している
 Microservices as Deep Services

  22. What Is a Microservice?
 • Ousterhoutは右図のようにモジュールを長方 形で視覚化している
 • 上端はモジュールの機能、またはパブリックイ ンターフェースの複雑さを表す


    • 幅の広い四角形はより広い機能を表し、幅の 狭い四角形はより制限された機能を持つ 
 • このモデルによると、効果的なモジュールは深 く、単純なパブリックインターフェースが複雑な ロジックをカプセル化する
 • 逆に効果のないモジュールは浅い

  23. What Is a Microservice?
 • 右のメソッドは浅いモジュールの極端 なケースである
 • パブリックインターフェースとそのロジッ クが全く一緒


    • このようなモジュールを使用すると、無 関係な「可動部品」が導入されるため、 包括的なシステムに偶発的な複雑さが 追加される

  24. What Is a Microservice?
 • モジュールは論理境界であり、マイクロサービスは物理境界であるが、それ以 外の点では概念と基礎となる設計原理は同じ
 • 単一のビジネスメソッドを実装するサービスは浅いモジュールである
 ◦

    統合関連のパブリックメソッドを導入する必要があったため、結果として得 られるインターフェースは本来よりも幅広くなる
 • 深いモジュールはシステムのグローバルな複雑さを軽減し、浅いモジュールは ローカルの複雑さをカプセル化しないコンポーネントによって複雑さを高める
 • 浅いサービスは非常に多くのマイクロサービス指向のプロジェクトが失敗する理 由でもある
 Microservices as Deep Modules

  25. What Is a Microservice?
 • システムをマイクロサービスに分解できるしきい値 は、マイクロサービスが属するシステムのユースケー スによって定義される
 • モノリスをサービスに分解すると変更のコストが下が

    る
 • ただしマイクロサービスのしきい値を超えて分解し続 けるとディープサービスは浅くなっていく
 • 統合の必要性により、変更を導入するコストも上昇 し、システム全体のアーキテクチャは恐ろしい分散さ れた大きな泥だんごになってしまう

  26. 14-3. Domain-Driven Design and Microservices’ Boundaries / ドメイン駆動設計とマイクロサービスの 境界

  27. Domain-Driven Design and Microservices’ Boundaries
 境界づけられたコンテクストはモデルの境界であり、サブドメインはビジネス機能を 境界であり、集約オブジェクトと値オブジェクトはトランザクション境界である
 これらの境界のどれがマイクロサービスの概念に適しているかを見ていこう


  28. Domain-Driven Design and Microservices’ Boundaries
 • マイクロサービスと境界づけられたコンテクストには多くの共通点があるため 同じ意味で使用されることがある
 • マイクロサービスと境界づけられたコンテクストはどちらも物理的な境界である


    • マイクロサービスは境界づけられたコンテクストとして1つのチームによって所 有される
 • 境界づけられたコンテクストと同様、競合するモデルをマイクロサービスに実装 できないため、インターフェースは複雑になる
 • マイクロサービスは確かに境界づけられたコンテクストであるが、逆に境界づ けられたコンテクストはマイクロサービスと言えるだろうか?
 Bounded Contexts

  29. Domain-Driven Design and Microservices’ Boundaries
 • 第三章で学習したように、境界づけられたコンテクストはユビキタス言語とモデ ルの一貫性を保護する
 • 競合するモデルを同じ境界づけられたコンテクストに実装することはできない


    • 例えば下のように広告管理システムでは、LeadはPromotionsコンテクストと Salesコンテクストで異なるモデルで表されている

  30. Domain-Driven Design and Microservices’ Boundaries
 • Lead以外にシステムに競合するモデル がないと仮定する
 • これにより境界づけられたコンテクスト

    は自然に広くなり、各コンテクストには 複数のサブドメインを含めることができ る
 • サブドメインは、あるコンテストから別の コンテクストに移動できる
 • サブドメインが競合するモデルを暗示し ない限り、右図のすべての代替分解は 完全に有効な境界づけられたコンテク ストである

  31. Domain-Driven Design and Microservices’ Boundaries
 • 境界づけられたコンテクストに対する分解は、チームのサイズと構造、ライフサイ クルの依存関係など、様々な要件に起因する
 • この例から全ての境界づけられたコンテクストは、必然的にマイクロサービスとな

    るとは言えない
 • マイクロサービスと境界づけられたコンテクストの関係は対象ではない
 • マイクロサービスは境界づけられたコンテクストであるが、全ての境界づけられた コンテクストがマイクロサービスであるとは限らない
 • 一方、境界づけられたコンテクストは最大の有効なモノリスの境界を示す
 • そのようなモノリスは大きな泥だんごと混同してはいけない
 • ユビキタス言語またはビジネスドメインのモデルの一貫性を保護する実行可能な 設計オプションである

  32. Domain-Driven Design and Microservices’ Boundaries
 • 右図は境界づけられたコンテクストとマ イクロサービスの関係性である
 • 境界づけられたコンテストとマイクロ

    サービス間の領域は安全であり、有効 なデザインオプションである
 • システムが適切なコンテクストに分解さ れていない場合やマイクロサービスの しきい値を超えて分解された場合、大き な泥だんごか分散された大きな泥だん ごになってしまう

  33. Domain-Driven Design and Microservices’ Boundaries
 • 境界づけられたコンテクストは最も広い有効な境界に制限を課すが、集約はそ の逆を行う
 • 集約の境界は可能な限り狭い境界である


    • 集約を複数の物理サービスまたはコンテクストに分解することは望ましくない 結果に繋がってしまう
 • 境界づけられたコンテクストとして、集約の境界もマイクロサービスの境界を駆 動する
 Aggregates

  34. Domain-Driven Design and Microservices’ Boundaries
 • 集約は、内部のビジネスルール、不変条件、ロジックの複雑さをカプセル化する不 可分のビジネス機能単位である
 • とはいえ、マイクロサービスは各サービスの相互作用を考慮する必要がある


    • 集約と他のビジネスエンティティとの関係が強いほど、個々のサービスとしては浅 くなる
 • 集約をサービスとして使用すると、モジュラー設計が生成される場合があるが、多 くの場合このようなきめ細かいサービスはシステム全体の複雑さを増やしてしまう

  35. Domain-Driven Design and Microservices’ Boundaries
 • マイクロサービスを設計するためのよりバランスの取れたヒューリスティックは サービスをビジネスサブドメインの境界に合わせることである
 • サブドメインはきめ細かなビジネス機能と相関している


    • これらは企業がそのビジネスドメインで競争するために必要なビジネスの単位で ある
 • ビジネスドメインの観点から見ると、サブドメインは機能の実装方法を説明せず に、機能(ビジネスの動作)を記述する
 • 技術的な観点から見ると、サブドメインはビジネスドメインの同じモデルを使用 し、密接に関連するデータを処理し、強力な機能的関係を持つという、一貫した ユースケースのセットを表す
 Subdomains

  36. Domain-Driven Design and Microservices’ Boundaries
 下図では1つのユースケースのビジネス要件の変更は他のユースケースに影響を与 える可能性がある


  37. Domain-Driven Design and Microservices’ Boundaries
 • サブドメインの粒度と機能に焦点を当てることで、サブドメインは自然に深いモジュール になる
 • サブドメインの説明(関数)はより複雑な実装の詳細(ロジック)をカプセル化する


    • サブドメインに含まれるユースケースの一貫性により、モジュールの深さも保証される
 • 多くの場合、それらを分割するとパブリックインターフェースがより複雑になり、モジュー ルが浅くなる
 • サブドメインはマイクロサービスを設計するための安全な境界である
 • とはいえ、組織の構造やビジネス戦略、非機能要件によってソリューションが変わるの で、他の境界が最適な場合もある

  38. 14-4. Compressing Microservices’ Public Interface / 包括的なマイクロサービスのパブリックイ ンターフェース

  39. Compressing Microservices’ Public Interfaces
 • サービス境界を見つけることに加えて、ドメイン駆動設計はサービスをより深くす るのに役立つ
 • このセクションではオープンホストサービスと腐敗防止層を使用して、マイクロ サービスのパブリックインターフェースを簡略化する方法を示す


  40. Compressing Microservices’ Public Interfaces
 • オープンホストサービスは右図のように境界づけられ たコンテクストのモデルを他のコンポーネントとの統合 に使用されるモデルから切り離す
 • 公開言語である統合指向モデルを導入することで、シ

    ステムのグローバルな複雑さが軽減される
 • コンシューマに影響を与えることなくサービスの実装を 進化させることができる
 • 統合のニーズを中心に設計されるため、コンシューマ に関係のない実装の複雑さをカプセル化できる
 • 単純なパブリックインターフェースを持つことでサービ スが「深く」なり効果的なマイクロサービス設計に貢献 する
 Open-Host Service

  41. Compressing Microservices’ Public Interfaces
 • 腐敗防止層(ACL)はオープンホストサービス とは逆の方法で機能する
 • サービスを他のコンテクストと統合する際の 複雑さが軽減される


    • 右図のACLサービスは、コンシューマのコン テクストのローカルの複雑さとシステムのグ ローバルな複雑さの両方を軽減する
 Anticorruption Layer

  42. 14-5. Conclusion / 結論

  43. Conclusion • 歴史的にマイクロサービスと境界づけられたコンテクストは同じ意味で使用されることがあ る
 • この章では、2つの関係を分析し同じものではないことを確認した 
 • 全てのマイクロサービスは境界づけられたコンテクストであるが、全ての境界づけられたコ ンテスクストが必ずしもマクロサービスであるとは限らない

    
 • 本質的にマイクロサービスは有効な最小の境界を定義し、境界づけられたコンテクストは 包含されたモデルの一貫性を保護し、最も広い有効な境界を表す 
 • 境界づけられたコンテクストよりも広く定義すると、大きな泥だんごが生成され、マイクロ サービスよりも小さい境界は分散された大きな泥だんごになる 
 • それにもかかわらず、マイクロサービスとドメイン駆動設計の接続は緊密である 
 • ドメイン駆動設計のツールを使用して、効果的なマイクロサービス境界を設計する方法を 確認した

  44. 14-6. Exercises / エクササイズ

  45. Exercises / エクササイズ
 1. 境界づけられたコンテクストとマイクロサービスの関係性は次のうちど れでしょう?
 a. すべてのマイクロサービスは境界づけられたコンテクスト
 b. すべての境界づけられたコンテクストはマイクロサービス


    c. マイクロサービスと境界づけられたコンテクストは同じ概念の異な る用語
 d. マイクロサービスと境界づけられたコンテクストは完全に異なる概 念であり、比較することはできない

  46. Exercises / エクササイズ
 1. 境界づけられたコンテクストとマイクロサービスの関係性は次のうちど れでしょう?
 a. すべてのマイクロサービスは境界づけられたコンテクスト
 b. すべての境界づけられたコンテクストはマイクロサービス


    c. マイクロサービスと境界づけられたコンテクストは同じ概念の異な る用語
 d. マイクロサービスと境界づけられたコンテクストは完全に異なる概 念であり、比較することはできない

  47. Exercises / エクササイズ
 2. マイクロサービスのどの部分を「マイクロ」にする必要が
   あるでしょうか?
 a. マイクロサービスを実装するチームにフィードするために必要なピザの数。メトリク スはチームメンバーのさまざまな食事の好みと毎日の平均カロリー摂取量を考慮 に入れる必要がある

    
 b. サービスの機能を実現するために必要なコードの行数。メトリクスは線の幅に依存 しないため、ウルトラワイドモニターにマイクロサービスを実装することをおすすめし ます
 c. マイクロサービスベースのシステムを設計する上で最も重要なのは、できればマイ クロサービス認定ベンダーから、マイクロサービスに適したミドルウェアやその他の インフラストラクチャコンポーネントを入手すること 
 d. サービス境界を越えて公開され、そのパブリックインターフェースに反映されるビジ ネスドメインとその複雑さに関する知識 

  48. Exercises / エクササイズ
 2. マイクロサービスのどの部分を「マイクロ」にする必要が
   あるでしょうか?
 a. マイクロサービスを実装するチームにフィードするために必要なピザの数。メトリク スはチームメンバーのさまざまな食事の好みと毎日の平均カロリー摂取量を考慮 に入れる必要がある

    
 b. サービスの機能を実現するために必要なコードの行数。メトリクスは線の幅に依存 しないため、ウルトラワイドモニターにマイクロサービスを実装することをおすすめし ます
 c. マイクロサービスベースのシステムを設計する上で最も重要なのは、できればマイ クロサービス認定ベンダーから、マイクロサービスに適したミドルウェアやその他の インフラストラクチャコンポーネントを入手すること 
 d. サービス境界を越えて公開され、そのパブリックインターフェースに反映されるビジ ネスドメインとその複雑さに関する知識 

  49. Exercises / エクササイズ
 3. 安全なコンポーネント境界はなんでしょう?
 a. 境界づけられたコンテクストよりも広い
 b. マイクロサービスよりも境界が狭い
 c.

    境界づけられたコンテクスト(最も広い)とマイクロサービス(最も狭 い)の間の境界
 d. すべての境界は安全である

  50. Exercises / エクササイズ
 3. 安全なコンポーネント境界はなんでしょう?
 a. 境界づけられたコンテクストよりも広い
 b. マイクロサービスよりも境界が狭い
 c.

    境界づけられたコンテクスト(最も広い)とマイクロサービス(最も狭 い)の間の境界
 d. すべての境界は安全である

  51. Exercises / エクササイズ
 4. マイクロサービスを集約の境界に合わせることは
 良い設計上の決定でしょうか?
 a. はい、集約は常に適切なマイクロサービスを実現する
 b. いいえ、集約を個々のマイクロサービスとして公開してはいけない


    c. 単一の集約からマイクロサービスを作ることはできない
 d. ビジネスドメインによって異なる