コードレプリケーションとは何か

—「結合するくらいなら重複しろ」の真意—

来ましたね、「コードレプリケーション」。

プログラミングスクールで
「コピペは悪！DRY原則（Don't Repeat Yourself）を守れ！」
って教わって、それを戒律みたいに信じてる人、結構おるよな。

でもな、マイクロサービスの世界では、真逆のことが言われる。

結合するくらいなら、重複しろ

「えっ、コピペしていいんですか……？」
って顔してるお前、
その反応がもう“結合依存体質”や。

ここでは
『ソフトウェアアーキテクチャ・ハードパーツ』第8章に出てくる
「境界づけられたコンテキストを維持する（Maintains Bounded Contexts）」
というメリットを、叩き込む。

---

1. 「共有」は地獄の始まり

まずな、このメリットを理解するには
「共有ライブラリ」の怖さを知らなあかん。

お前らが大好きな「共通ライブラリ」な。
便利やと思って、何でもかんでも突っ込むやろ？

• サービスA

  「この共通関数、仕様ちょっと変えてほしいな〜」

• 共通ライブラリ担当

  「はい、変えました！」

• サービスB

  「ギャー！勝手に仕様変わってて動かん！」

これが何か分かるか？

**結合（Coupling）**や。

サービスAの都合で、
全く関係ないサービスBが巻き添えを食らってる。

• 変更の影響範囲が全サービスに波及
• 全体デプロイが必要
• 誰も触りたくないコードになる

「共通化して効率的です（ドヤァ）」
その結果がデプロイ地獄や。

---

2. コードレプリケーションという「完全な鎖国」

そこで出てくるのが コードレプリケーション。

これは何かというと、

共有コードをライブラリにせず、
各サービスに物理的にコピーして持つ

という戦略や。

境界づけられたコンテキストを維持する、とは？

要するにこういうことや。

• コードをコピーして自分たちのリポジトリに置く
• それはもう 「自分たちのモノ」
• 他サービスは一切口出しできない

つまり、

他人の都合に振り回されへん

サービスAがどれだけ魔改造しようが、
サービスBのコピーには一切影響なし。

これが
境界（テリトリー）を守る
ということや。

---

3. ただし、代償はクソ重い

ここで勘違いしたらアカン。

「じゃあ全部コピペすればええやん！」

それは思考停止や。

この手法には、
明確で重いデメリットがある。

保守性の低下

もしコピペしたコードにバグがあったら？

• 10サービス → 10回修正
• 50サービス → 50回修正

地獄や。

これは
「小4のとき、病気で帽子かぶってたのに無理やり脱がしてきた塾の先生」
並みに理不尽や。

---

結論：使いどころを見極めろ

せやから結論はこれや。

コードレプリケーションを使っていいのは？

• 一度書いたら、ほぼ変更されないコ