BT

InfoQ ホームページ ニュース マイクロサービスのコード共有

マイクロサービスのコード共有

ブックマーク

原文(投稿日:2015/01/25)へのリンク

マイクロサービスを開発する理由の多くは,変更に対処する手段としてのアイソレーションの利用にある。サービス間でコードを共有してしまうと,サービスが互いに関連付けられ,アイソレーションのバリアが乗り越えられることになり,アイソレーションの効果と変更への対応能力は低減する - David Daweonはこのように書いて,DRY(Don't Repeat Yourself)の原則に疑問を呈している

その名もSimplicityという会社のCEOである氏は,マイクロサービス開発の一般的な理由として,次のようなものを挙げている。

  • 独立したスケーリング
  • サービスの分離
  • サービスのライフサイクルの分離

これらの理由はすべて,環境ないしコードベースの変更に対処するものだ,と氏は言う。サービスの分割を考える上において,変更が主要な指針となることも少なくない,というのが氏の意見だ。

一方,開発者の立場から見れば,マイクロサービス間でコードを共有する理由は決して少なくない。氏が考えるのは,次のようなものだ。

  • 共有ライブラリなどによる,既存の技術的機能の活用。
  • 同じクラスを使用するなどの方法による,データスキーマの共有。
  • 別々のサービスから同じデータストアを使用するなど,データソースの共有。

ここで氏が強調するには,コードの共有が必然的に,そのコードを通じてサービスを結合することになる点だ。本当のソースをひとつだけ作成して,単一のサービス内でDRYの原則に従っているのであれば,内部的な結合は発生したとしても,単一の責任を持つサービスとして問題にはならない。これとは対照的に,サービスのバウンダリを越える場合には,例え同じような部分があったとしても,それぞれのコンテキストは異なっているのだから,異なるコードで実装し,異なるデータストアを使用する必要がある。いかに同じように見えようとも,サービスとサービスを結びつけるような行為には,我々は抵抗しなければならない,と氏は主張する。それがバウンダリやコンテキストを越えた結び付きを意味し,Big Ball of Mud(大きな泥団子)アーキテクチャに直結するからだ。

DRYの原則は,デザインパターンに匹敵するような,ソフトウェア開発の基本原理のひとつになったが,同時に“Don't Repeat Anything”や“Copy and Paste id bad”と曲解されているのではないか,と氏は考えている。そこでルーツに立ち戻って“The Pragmatic Programmer”を見ると,DRYの説明は次のようなものだ。

知識は,そのすべての部分が,システム内に単一で,明確で,信頼できる形で表現されなくてはなりません。

ここで重要なのは“知識”という概念であって,コピーや貼り付けではない,と氏は指摘する。この原則は特定の領域では有効ではあるが,用語がその文脈を離れて独り歩きしているのではないのだろうか,と言うのだ。マイクロサービスアーキテクチャにおいて,スキーマの共有のような高いレベルで適用された場合,DRYによってマイクロサービスが短絡されることになる。メリットは何もない,ただアーキテクチャのメンテナンスコストが残るだけなのだ。

この記事に星をつける

おすすめ度
スタイル

特集コンテンツ一覧

RESTlessnessに打ち勝つ

Matt McLarty 2019年3月13日 午前7時39分

.NET CLIクイックツアー

Jeremy Miller 2019年2月18日 午前1時55分

.NET CoreとDevOps

Dave Swersky 2019年2月6日 午後11時46分

こんにちは

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

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

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

コミュニティコメント

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

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

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。