BT

Ready for InfoQ 3.0? Try the new design and let us know what you think!

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

| 作者: Jan Stenberg フォローする 39 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2015年2月9日. 推定読書時間: 2 分 |

原文(投稿日: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によってマイクロサービスが短絡されることになる。メリットは何もない,ただアーキテクチャのメンテナンスコストが残るだけなのだ。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには 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でリプライする

ディスカッション

特集コンテンツ一覧

C# 8の非同期ストリーム

Bassam Alugili 2018年10月11日 午前3時13分

BT