コンテキスト境界(bounded context)とは、特定の用語や定義、規則が一貫した方法で適用されるソフトウェアの定義部分である — Eric Evans氏は今年初め、DDD Europeで行った基調講演で、このように解説した。正当なコンテキストには、洗練されたモデルと表現力のあるユビキタスな言語による、明確な定義がある。しかしながら、整然として見えるシステムの定義は、氏にとっては非常に疑わしいものだ。氏が関わった大規模なソフトウェアシステムは、いずれも整然としているとは言い難いものだったからだ。先日公開されたプレゼンテーションで、氏は、さまざまな種類のコンテキスト境界や、マイクロサービスとの関係について説明している。
DDDの思想的リーダであり、先駆的な書籍"Domain-Driven Design"の著者でもあるEvans氏は、概念としてのコンテキスト境界について、何年も前からコミュニティの関心は高まっているものの、まだまだやるべきことのある領域だ、と指摘する。Evans氏が開発チームで時々目にする混乱のひとつは、コンテキスト境界とサブドメインの区別に関するものだ。この２つは理想的な世界では一致するが、現実には不整合であることが少なくない。例として氏は、現金口座とクレジットカードを中心に構成された銀行を挙げている。銀行のドメイン内のこれら2つのサブドメインもまた、コンテキスト境界である。その後、ビジネス口座と個人口座を中心としたビジネスの再編成によって、これらとは別の2つのサブドメインが存在するようになったが、コンテキスト境界は同じままだ。従って、新たなサブドメインとは整合していないことになる。この結果、多くの場合において、2つのチームが同じコンテキスト境界で作業しなければならず、"大きな泥玉(big ball of mud)"化するリスクが高くなる。
成熟した生産的なコンテキストは価値を生み出すが、その多くは時代遅れのコアドメインの概念に基づいている。ここで問うべき重要な質問は、コアドメインの現在のビューと比較した時、コアドメインの不整合がどれ程のものか、これがビジネスの発展をどの程度制約しているか、ということだ。不整合が大きすぎると、既存のコンテキストを転換する要求が生じる可能性がある。しかしEvans氏の経験では、そのような転換はうまくいかないことが多い。ソフトウェアの基本的な前提の変更は、多くの場合、システムをだめにする。従って氏は、そのような方法には否定的だ。
Evans氏が取り上げた別のコンテキストのひとつは、Quaint(古風な)コンテキストと呼ぶべき古いコンテキストだ。機能的には今でも有用だが、旧式のテクノロジを使って実装されていたり、ドメインの現在のビジョンに沿っていない可能性がある。もうひとつはGeneric Off the Shelf(OTS)コンテキストとGenericサブドメインコンテキストの組み合わせで、他のコンテキストが準拠すべき重要なサブドメインを、従来の方法で総称的サブドメインとして定義するものだ。さらに氏は、GeneralistコンテキストとSpecialistトコンテキストについて説明し、その比較を行っている。
Evans氏はマイクロサービスについて、最大のチャンスであると同時に、我々が長く抱えていた最大のリスクであると考えている。我々が最も関心を持つべきことは、我々の従事するビシネスのニーズを満たす上において、マイクロサービスが果たすことのできる能力である。さらに氏は、その"バンドワゴン効果"についても警鐘を鳴らしている。氏が問題視する点のひとつは、マイクロサービスはすなわちコンテキスト境界である、と多くの人たちが信じていることだ。それは単純化し過ぎだ、と考える氏は、それに代わるものとして、マイクロサービスに関連する4種類のコンテキストを取り上げている。
第１の"Service Internal"は、サービスの動作方法について述べたものだ。マイクロサービスがコンテキスト境界であるという時、人々が思い浮かべるのはこのタイプだ、とEvans氏は言う。ここでは、サービスは他のサービスから分離され、自律的なチームによって処理される。コンテキスト境界の定義には適合しているが、それでは不十分だ、と氏は指摘する。このタイプだけを使用すると、相互に通信する方法の分からないサービスが出来上がることになるからだ。
第２の"API of Service"では、他のサービスとの通信を記述する。ここでの課題のひとつは、チームがそれぞれのAPIをどのように設計し、適応するか、にある。データフローの方向によって、コンシューマが常に上流のデータフローに準拠するように、開発の依存関係を決定することは可能だが、他にも方法があるとEvans氏は考える。高い影響力を持つグループがAPIを作成すれば、他のグループはそれに準拠しなければならない。例えばオーソリティに対しては、データの方向に関係なく、そのAPIに準拠しなければならないのが一般的だ。
3番目は"Cluster of codesigned services"である。複数のサービスが相互に連携して何かを達成するような設計の場合、それらはひとつになってコンテキスト境界を形成する。注目すべきなのは、個々のサービスの内部では、APIで使用するモデルとはまったく異なるモデルを使用することが可能である、ということだ。
最後のタイプは"Interchange Context"である。サービス間の相互作用もモデル化する必要がある、とEvans氏は指摘する。このコンテキストのモデルには、サービスが他のサービスと対話するときに使用するメッセージと定義を記述する。注目すべきは、このコンテキストにはサービスが存在しないことである。ここで取り上げるのは、メッセージ、スキーマ、そしてプロトコルなのだ。
Exposed Legacy Assetは、レガシシステムをマイクロサービス環境に参加させる場合に有効である。その方法のひとつは、マイクロサービスのように見えて、他のマイクロサービスと相互作用するが、内部的にはレガシシステムと処理を行うインターフェースを用意することだ。これにより、構築済の新しいマイクロサービスに手を加える必要も、レガシシステムを変更する必要も回避することが可能になる。レガシシステムは変更に対して脆弱で、障害を発生したり、大きな泥玉になる可能性も少なくないのだ。
最後にEvans氏は、DDDが実際に何であるかの定義を試みている。問題なのは、DDDをどの程度厳密に定義する必要があるのか、という点だ。定義には共通のビジョンと言語がなければならないが、イノベーションと改善を可能にする柔軟性も必要だ。コミュニティは重要だが、結果が期待したものでない場合、誤りを認めることのできる、誠実なコミュニティでなければならない。さらに氏は、DDDの適用可能性の限界も明確にすべきだ、すべてのプロジェクトがDDDで実施されるべきではない、とも考える。そのために氏は、コアドメインの重視、クリエイティブなコラボレーションによるモデルの模索、コンテキスト境界内における共通言語による会話、といった基本原則の集合としてDDDを定義している。氏の最後のことばは、次のとおりだ。
共にDDDを実践し、新たなものにしていきましょう。