モノリスにおいてもきちんとした方法でモデリングすることは可能ではあるが、しばしば大きな泥団子と化してしまう。これは複数のドメインモデルがモノリス内で絡まってしまうのが原因であり、Vaughn Vernon氏の経験ではこれは数週間もしくは数ヶ月以内に起こりうるのである。彼は今年初めの発表でこのように述べた。
Implementing Domain-Driven DesignとReactive Messaging Patterns with the Actor Modelの著者であるVernon氏は、分離すべきドメインモデルが混在した時、これらは互いに区別することはできなくなるため、ビジネスサイドやドメイン専門家と一緒にモデルについて論理的に検討することが困難、あるいは不可能となってしまい、アプリケーションやシステムはモノリスより更に悪化する結果を招いてしまうと記している。
モノリスの代替はマイクロサービスであるが、どうやってマイクロサービスを定義するのであろうか？これはどれくらいの大きさなのだろうか？時々コード行数がサイズの定義として提案され、Vernon氏は10行から1000行単位の数値を見たことがあるが、彼はそのような幅広く不明瞭な定義に異議を唱えている。
Vernon氏は100個単位のサービスを持っていると主張し、正確な数を把握することも知ろうともしない企業にも反発している。彼らはサービスを単に稼働させるコストはとても低いため、実際の使用方法を発見する努力を行うに値しないと主張している。Vernon氏はこれに賛同しておらず、他の事柄の中において、インフラストラクチャはどれくらいのマイクロサービスを実行できるか、その時障害シナリオに対して回復力があるかに大きなインパクトを持っていると記している。
Vernon氏はシステム内のマイクロサービスのサイズと数を決定するための規則に則ったアプローチであるドメイン駆動設計(DDD)のアプローチ、特に境界づけられたコンテキストを使用することを推奨している。彼はマイクロサービスコミュニティ内では時々境界づけられたコンテキストを単純に一つのエンティティとして定義しているが、とてもうまくいきそうにないことを発見している。代わりに、Vernon氏はユビキタス言語によりサイズが決定された、境界づけられたコンテキスト内でマイクロサービスをモデリングすることを好んでおり、Sam Newman氏の書籍であるBuilding Microservicesを引用している。
マイクロサービスに取り掛かるために、Vernon氏は一つの境界づけられたコンテキスト毎に一つのサービスから始めることを推奨している。彼は一つの境界づけられたコンテキスト内にマイクロサービスであると考えられる複数のコンポーネントを確認できる場合でさえも、それらの凝集性と協調動作はそれらが一つのサービス内で共存するべきであることを意味していると考えている。また、一つのサービスと一つの境界づけられたコンテキストは一つの配置可能なユニットとすることを推奨している。ただし、経験からこれらはより細粒度になってもよく、スケーラビリティに起因して一つの境界づけられたコンテキストに対応するマイクロサービスと配置可能なユニットを増やすことはあり得る。
エンティティに加え、ユビキタス言語はコマンドとイベントメッセージも含んでいる。これらのメッセージをイベント駆動アーキテクチャにおいて最終的に他のマイクロサービスで使用するためのイベント公開に用いることができる。Vernon氏はアクターモデルを使用したマイクロサービスを構築する例を挙げることで発表を締めくくっており、実装にはAkkaとScalaを用いている。
Rate this Article
- Editor Review
- Chief Editor Action