Learning Domain-Driven Design輪読会#16

Learning Domain-Driven Design  輪読会 #16  株式会社Showcase Gig   中島清貴
(@ahyataro)   #lddd_rindoku  Chapter 14. Microservices  

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

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

Microservices  • 2010年代半ば、マイクロサービスはソフトウェアエンジニアリング業界を席巻した  • その目的は、素早く変化、拡張するモダンシステムのニーズに対応し、クラウドコンピューティングの分散性に自然に適合することだった  • 多くの企業は、マイクロサービスベースのアーキテクチャによって提供される柔軟性を優先して、モノリシックコードベースを分解するという戦略的決定を下した
が、残念ながらその努力の多くはうまくいかなかった  • 柔軟なアーキテクチャの代わりに、モノリスよりもはるかに壊れやすく、塊状で、高価な設計である、分散した大きな泥だんごになってしまった   

Microservices    • マイクロサービスはDDD、特に境界づけられたコンテクストパターンに関連付けられることがよくある  • 多くの人は境界づけられたコンテクストとマイクロサービスを同じ意味で使用しているが、それは本当に同じものだろうか？  • この章では、ドメイン駆動設計とマイクロサービスのアーキテクチャパターンの関
係と、DDDを活用して効果的なマイクロサービスベースのシステムを設計する方法を学習する   

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

What Is a Service? • OASISによると、サービスとは1つ以上の機能へのアクセスを可能にするメカニズムであり、アクセスは規定のインターフェースを使用して提供される  • 規定のインターフェースはサービスにデータを入れたり、サービスからデータを取得したりするためのメカニズム 
• 他のシステムコンポーネントと通信および統合する手段を提供するパブリックインターフェースである 

What Is a Service?  • Randy Shoupは、サービスのインターフェースを正面玄関に例えている  • サービスに出入りする全てのデータは、正面
玄関を通過する必要がある  • サービスのパブリックインターフェースはサービス自体を定義する  • 適切に表現されたインターフェースはサービスによって実装される機能を十分に記述する 

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

What Is a Microservice?  • マイクロサービスはマイクロパブリックインターフェースを持つサービス  • マイクロパブリックインターフェースを使用すると、単一のサービスの機能と他のシステムコンポーネントとの統合の両方を理解しやすくなる  •
サービスの機能を減らすと、変更の理由も制限され、開発、管理、スケーリングに対してサービスがより自律的になる  • マイクロサービスはデータベースを公開しない  • データベースを公開し、サービスのフロントドアの一部にすると、そのパブリックインターフェースは巨大になる(SQLは無数のクエリを発行できるため)  • したがって、マイクロサービスはデータベースをカプセル化する 

What Is a Microservice?  • マイクロサービスがマイクロパブリックインターフェースであるというのは、一見単純である  • サービスインターフェースを1つのメソッドに制限すると完全なマイクロサービスを得られるように聞こえるかもしれない 
• この素朴な分解を実際に適用すると以下のようになる  Method as a Service: Perfect Microservice? 

What Is a Microservice?  • パブリックインターフェースは8つのパブリックメソッドで構成されており、「サービスごとに1つのメソッド」ルールが適用されている  • それぞれのサービスはデータベースをカプセル化する  •
別のサービスのデータベースに直接アクセスすることはできず、パブリックインターフェースを介すことしかできない  • しかし、そのためのパブリックインターフェースはない 

What Is a Microservice?  • サービスは連携して動作し、各サービスが適用している変更を同期する必要がある  • その結果、これらの統合関連の懸念
に対応するために、サービスのインターフェースを拡張する必要がある  • サービス間の統合とデータフローは右図のように典型的な分散された大きな泥だんごになる 

What Is a Microservice?  • システムをこのようなきめ細かなサービスに分解することで、サービスのフロントドアを最小限に抑えたと言える  • ただし包括的なシステムの機能を実装するには、各サービスに膨大な「スタッフのみ」の入り口を追加する必要になった 
• このことから、各サービスに1つのメソッドのみを公開させるという単純な分解ヒューリスティックは多くの理由で最適でないことが判明した  ◦ サービスは連携する必要があるので、統合関連のパブリックメソッドを使用してパブリックインターフェースを拡張することを余儀なくされた  ◦ 各サービスは元の設計よりもはるかに単純にはなったが、全体のシステムは桁違いに複雑になってしまった 

What Is a Microservice?  • マイクロサービスアーキテクチャの目標は柔軟なシステムを作ること  • 設計作業を単一のコンポーネントに集中させ、システムの他の部分との相互作用を無視することは、システムの定義そのものに反する  •
独立したコンポーネントからシステムを構築することはできない  • 適切なマイクロサービスベースのシステムでは、たとえ分離されていてもサービスを統合して相互に通信する必要がある  • 個々のマイクロサービスの複雑さと包括的なシステムの複雑さの相互作用を見ていこう  Design Goal 

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

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). 複雑さの主題には、プログラムの各部分の局所的な複雑さを単に最小限に抑えようとするよりはるかに多くのことがある。複雑さのはるかに重要なタイプは、グローバルな複雑さ、つまりプログラムまたはシステムの全体的な構造の複雑さ(つまり、プログラムの主要な部分間の関連性または相互依存の程度)である 

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

What Is a Microservice?  • グローバルな複雑さを最小限に抑えるのは簡単  • 必要なのは、システムのコンポーネント間の相互作用を排除すること、つまり全ての機能を1つのモノリシックサービスに実装することだけ  •
この戦略は特定のシナリオで機能する可能性はあるが、恐ろしい大きな泥だんごに繋がる可能性もある  • 一方で局所的な複雑さのみを最適化し、システムのグローバルな複雑さ、つまりさらに恐ろしい分散された大きな泥だんごを無視するとどうなるかもわかっている 

What Is a Microservice?  • 適切なマイクロサービスベースのシステムを設計するには、グローバルとローカルの両方の複雑さを最適化する必要がある  •
どちらかを個別に最適化するという設計目標を設定することは局所最適である 

What Is a Microservice?  • ソフトウェアシステムまたは任意のモジュールはその機能とロジックによって定義される  • 関数はモジュールが行うことになっていること、つまりそのビジネス機能である  •
ロジックはモジュールのビジネスロジックであり、モジュールがビジネス機能を実現する方法である  • John Ousterhoutは、著書「The Philosophy of Software Design」でモジュール性の概念について議論し、モジュールの設計を評価するためのシンプルでありながら強力な視覚的ヒューリスティックである深さを提案している  Microservices as Deep Services 

What Is a Microservice?  • Ousterhoutは右図のようにモジュールを長方形で視覚化している  • 上端はモジュールの機能、またはパブリックインターフェースの複雑さを表す 
• 幅の広い四角形はより広い機能を表し、幅の狭い四角形はより制限された機能を持つ   • このモデルによると、効果的なモジュールは深く、単純なパブリックインターフェースが複雑なロジックをカプセル化する  • 逆に効果のないモジュールは浅い 

What Is a Microservice?  • 右のメソッドは浅いモジュールの極端なケースである  • パブリックインターフェースとそのロジックが全く一緒 
• このようなモジュールを使用すると、無関係な「可動部品」が導入されるため、包括的なシステムに偶発的な複雑さが追加される 

What Is a Microservice?  • モジュールは論理境界であり、マイクロサービスは物理境界であるが、それ以外の点では概念と基礎となる設計原理は同じ  • 単一のビジネスメソッドを実装するサービスは浅いモジュールである  ◦
統合関連のパブリックメソッドを導入する必要があったため、結果として得られるインターフェースは本来よりも幅広くなる  • 深いモジュールはシステムのグローバルな複雑さを軽減し、浅いモジュールはローカルの複雑さをカプセル化しないコンポーネントによって複雑さを高める  • 浅いサービスは非常に多くのマイクロサービス指向のプロジェクトが失敗する理由でもある  Microservices as Deep Modules 

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

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

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

Domain-Driven Design and Microservices’ Boundaries  • マイクロサービスと境界づけられたコンテクストには多くの共通点があるため同じ意味で使用されることがある  • マイクロサービスと境界づけられたコンテクストはどちらも物理的な境界である 
• マイクロサービスは境界づけられたコンテクストとして1つのチームによって所有される  • 境界づけられたコンテクストと同様、競合するモデルをマイクロサービスに実装できないため、インターフェースは複雑になる  • マイクロサービスは確かに境界づけられたコンテクストであるが、逆に境界づけられたコンテクストはマイクロサービスと言えるだろうか？  Bounded Contexts 

Domain-Driven Design and Microservices’ Boundaries  • 第三章で学習したように、境界づけられたコンテクストはユビキタス言語とモデルの一貫性を保護する  • 競合するモデルを同じ境界づけられたコンテクストに実装することはできない 
• 例えば下のように広告管理システムでは、LeadはPromotionsコンテクストと Salesコンテクストで異なるモデルで表されている 

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

Domain-Driven Design and Microservices’ Boundaries  • 境界づけられたコンテクストに対する分解は、チームのサイズと構造、ライフサイクルの依存関係など、様々な要件に起因する  • この例から全ての境界づけられたコンテクストは、必然的にマイクロサービスとな
るとは言えない  • マイクロサービスと境界づけられたコンテクストの関係は対象ではない  • マイクロサービスは境界づけられたコンテクストであるが、全ての境界づけられたコンテクストがマイクロサービスであるとは限らない  • 一方、境界づけられたコンテクストは最大の有効なモノリスの境界を示す  • そのようなモノリスは大きな泥だんごと混同してはいけない  • ユビキタス言語またはビジネスドメインのモデルの一貫性を保護する実行可能な設計オプションである 

Domain-Driven Design and Microservices’ Boundaries  • 右図は境界づけられたコンテクストとマイクロサービスの関係性である  • 境界づけられたコンテストとマイクロ
サービス間の領域は安全であり、有効なデザインオプションである  • システムが適切なコンテクストに分解されていない場合やマイクロサービスのしきい値を超えて分解された場合、大きな泥だんごか分散された大きな泥だんごになってしまう 

Domain-Driven Design and Microservices’ Boundaries  • 境界づけられたコンテクストは最も広い有効な境界に制限を課すが、集約はその逆を行う  • 集約の境界は可能な限り狭い境界である 
• 集約を複数の物理サービスまたはコンテクストに分解することは望ましくない結果に繋がってしまう  • 境界づけられたコンテクストとして、集約の境界もマイクロサービスの境界を駆動する  Aggregates 

Domain-Driven Design and Microservices’ Boundaries  • 集約は、内部のビジネスルール、不変条件、ロジックの複雑さをカプセル化する不可分のビジネス機能単位である  • とはいえ、マイクロサービスは各サービスの相互作用を考慮する必要がある 
• 集約と他のビジネスエンティティとの関係が強いほど、個々のサービスとしては浅くなる  • 集約をサービスとして使用すると、モジュラー設計が生成される場合があるが、多くの場合このようなきめ細かいサービスはシステム全体の複雑さを増やしてしまう 

Domain-Driven Design and Microservices’ Boundaries  • マイクロサービスを設計するためのよりバランスの取れたヒューリスティックはサービスをビジネスサブドメインの境界に合わせることである  • サブドメインはきめ細かなビジネス機能と相関している 
• これらは企業がそのビジネスドメインで競争するために必要なビジネスの単位である  • ビジネスドメインの観点から見ると、サブドメインは機能の実装方法を説明せずに、機能(ビジネスの動作)を記述する  • 技術的な観点から見ると、サブドメインはビジネスドメインの同じモデルを使用し、密接に関連するデータを処理し、強力な機能的関係を持つという、一貫したユースケースのセットを表す  Subdomains 

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

Domain-Driven Design and Microservices’ Boundaries  • サブドメインの粒度と機能に焦点を当てることで、サブドメインは自然に深いモジュールになる  • サブドメインの説明(関数)はより複雑な実装の詳細(ロジック)をカプセル化する 
• サブドメインに含まれるユースケースの一貫性により、モジュールの深さも保証される  • 多くの場合、それらを分割するとパブリックインターフェースがより複雑になり、モジュールが浅くなる  • サブドメインはマイクロサービスを設計するための安全な境界である  • とはいえ、組織の構造やビジネス戦略、非機能要件によってソリューションが変わるので、他の境界が最適な場合もある 

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

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

Compressing Microservices’ Public Interfaces  • オープンホストサービスは右図のように境界づけられたコンテクストのモデルを他のコンポーネントとの統合に使用されるモデルから切り離す  • 公開言語である統合指向モデルを導入することで、シ
ステムのグローバルな複雑さが軽減される  • コンシューマに影響を与えることなくサービスの実装を進化させることができる  • 統合のニーズを中心に設計されるため、コンシューマに関係のない実装の複雑さをカプセル化できる  • 単純なパブリックインターフェースを持つことでサービスが「深く」なり効果的なマイクロサービス設計に貢献する  Open-Host Service 

Compressing Microservices’ Public Interfaces  • 腐敗防止層(ACL)はオープンホストサービスとは逆の方法で機能する  • サービスを他のコンテクストと統合する際の複雑さが軽減される 
• 右図のACLサービスは、コンシューマのコンテクストのローカルの複雑さとシステムのグローバルな複雑さの両方を軽減する  Anticorruption Layer 

14-5. Conclusion / 結論

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

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

Exercises / エクササイズ  1. 境界づけられたコンテクストとマイクロサービスの関係性は次のうちどれでしょう？  a. すべてのマイクロサービスは境界づけられたコンテクスト  b. すべての境界づけられたコンテクストはマイクロサービス 
c. マイクロサービスと境界づけられたコンテクストは同じ概念の異なる用語  d. マイクロサービスと境界づけられたコンテクストは完全に異なる概念であり、比較することはできない 

Exercises / エクササイズ  2. マイクロサービスのどの部分を「マイクロ」にする必要が  　　あるでしょうか？  a. マイクロサービスを実装するチームにフィードするために必要なピザの数。メトリクスはチームメンバーのさまざまな食事の好みと毎日の平均カロリー摂取量を考慮に入れる必要がある
  b. サービスの機能を実現するために必要なコードの行数。メトリクスは線の幅に依存しないため、ウルトラワイドモニターにマイクロサービスを実装することをおすすめします  c. マイクロサービスベースのシステムを設計する上で最も重要なのは、できればマイクロサービス認定ベンダーから、マイクロサービスに適したミドルウェアやその他のインフラストラクチャコンポーネントを入手すること   d. サービス境界を越えて公開され、そのパブリックインターフェースに反映されるビジネスドメインとその複雑さに関する知識  

Exercises / エクササイズ  3. 安全なコンポーネント境界はなんでしょう？  a. 境界づけられたコンテクストよりも広い  b. マイクロサービスよりも境界が狭い  c.
境界づけられたコンテクスト(最も広い)とマイクロサービス(最も狭い)の間の境界  d. すべての境界は安全である 

Exercises / エクササイズ  4. マイクロサービスを集約の境界に合わせることは  良い設計上の決定でしょうか？  a. はい、集約は常に適切なマイクロサービスを実現する  b. いいえ、集約を個々のマイクロサービスとして公開してはいけない 
c. 単一の集約からマイクロサービスを作ることはできない  d. ビジネスドメインによって異なる 

Learning Domain-Driven Design輪読会#16

Learning Domain-Driven Design輪読会#16

kyotak

More Decks by kyotak

Featured

Transcript