BT

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

| 作者: Mikael Zandin , 翻訳者 徳武 聡 投稿日 2016年5月16日. 推定読書時間: 1分未満 |

原文(投稿日:2016/04/22)へのリンク

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

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

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

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

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

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

 

 
 

Rate this Article

Relevance
Style
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT