ドメイン駆動設計とマイクロサービス

ロンドンで開催されたQConカンファレンスでDomain Driven Design, Tackling Complexity at the Heart of Softwareの著者であるEric Evans氏は、ドメイン駆動設計(DDD)の概念はマイクロサービス環境でのユビキタス言語の複雑さを緩和すると話した。

チームのそれぞれのユビキタス言語はマイクロサービス環境を管理する上で特別な問題を生む。チームはそれぞれのユビキタス言語を作り、ドメインの範囲に従って意味を込める。しかし、そのようなユビキタス言語はチームのコンテキストを超えた一貫性を維持しない。あるチームの“customer”が他のチームの定義と大きくことなるかもしれない。それによって不要な複雑さが生み出される。それぞれの言語がそれぞれのチームのスコープで進化するが、別々の定義がある時点で存在することは間違いない。

氏はチームがコーディングのミスをしたり要件を誤解して障害や悪いコードが生まれることについて話す。このような失敗が、無関係のマイクロサービスに障害を起こしてしまうということが最悪のシナリオだ。氏はひとつのマイクロサービスに含まれる問題である“小さな泥だんご”と環境全体に広がってしまたひとつのマイクロサービスの問題である“大きな泥だんご”を区別する。

氏は3つのDDDのツールを紹介した。これは、マイクロサービスの環境を管理するのに使える。コンテキストマップと防腐レイヤ(ACL)と交換コンテキストだ。コンテキストマップはマイクロサービス間のコミュニケーションを表現し、マイクロサービスチームの間の適切なやりとりを支援する。この分析が成熟すると違うチームのドメイン言語から独立するという選択ができるようになる。このときに役立つのがACLだ。ACLの責務は、ドメイン間を疎結合にしつつ、外部の概念を内部のモデルに転換する。ふたつのチームが単なるパートナー以上の関係を持つ必要があるなら、交換コンテキストが役に立つかもしれない。交換コンテキストはACLよりも強力だ。両方のチームが言葉の意味を議論しマイクロサービスの言葉を変換する。

一枚岩のシステムからマイクロサービスにコードを移行するということはコンテキストの複雑さをコードからサービスの間に移行するということだ。マイクロサービス間のやりとりには既存のロジックが簡単に読みデバッグできるコードとして含まれている。新しいコンテキストは管理しなければならない。さもなければ、システムの全体を氏がいう“大きな泥だんご”にゆだねるかだ。

氏は境界付けられたコンテキストによって各マイクロサービスを設計することを推奨している。システム内のマイクロサービスを機能とユビキタス言語を使って論理的な境界で別けるのだ。それぞれの独立したチームはシステムの論理的に定義された一部分に対して責任を背負う。その結果、チームが生み出すコードはより理解しやすくメンテナンスしやすい。