はじめに
こんにちは。スポットバイトルを開発している、新卒エンジニアの伊藤です。
2026 年 9 月 11 日に開催された Go Conference 2026 に、ディップはGoルドスポンサーとしてブースを出展しました。
ブースで私たちが来場者に投げかけた質問は 1 つだけです。
「バックエンドで、どこまでカプセル化しますか？」
型で守るのか、lint で守るのか、テストか、レビューか、それとも守るのを諦めたか。普段使っている言語ごとに付箋を貼ってもらいながら、来場者の方と話し込みました。この記事では、ボードに集まった答えと、そこで交わされた会話、そしてディップ自身が「どこまで守り、どこを諦めたか」をまとめます。
Go Conference 2026 イベント概要
Go Conference 2026 は、Go 言語をテーマにした国内最大級のカンファレンスです。
今年は 9 月 11 日（金）に中野セントラルパークカンファレンスで開催され、セッションと並行してスポンサーブースが並びました。
ディップは Goルドスポンサーとして参加し、ブースを運営していました。
当日の様子
ディップのブース紹介
なぜこの質問だったのか
ディップでは、提供しているプロダクトの多くで、ドメイン駆動設計（DDD）を使って業務を整理し、事業とロジックを繋げることを進めています。バックエンドの言語は 1 つではなく、たとえばバイトルでは Kotlin、スポットバイトルでは Go、というようにプロダクトごとに使い分けています。
ただ、使い分けの軸は言語の好みではなく、事業のどの部分を守っているかです。
複数言語で同じ設計思想を貫こうとすると、すぐに 1 つの壁にぶつかります。「DDD をどれだけ厳密にやるか」は、言語の性質で変わる のです。
求人や応募の記録のように、正しさがそのまま事業の信用になる領域——いわゆる SoR（System of Record）——では、「不正な状態をそもそも作れない」ことを最優先にして厳格に守ります。一方、ユーザーとの接点で試行錯誤を繰り返す領域——SoE（System of Engagement）——では、厳格さより変更の速さを取り、守る範囲を意図的に狭くします。プロダクトの規模も同じ軸に乗ります。関わる人とコンテキストが増えるほど「人が守る」は効かなくなるので、機械で守る側に寄せていく。ディップは複数のプロダクトを持っているので、それぞれで守り方のパターンを変えて試している、というのが実態です。
つまり「どこまでカプセル化するか」は、私たちにとって言語の問題である前に、事業のどこを守るかの問題でした。そのうえで、複数言語で同じ設計思想を貫こうとすると、すぐにもう 1 つの壁にぶつかります。「DDD をどれだけ厳密にやるか」は、言語の性質で変わるのです。
Kotlin（や Java）なら、コンストラクタを閉じれば「不正な値のオブジェクトは作れない」を型で言い切れます。Go はそうはいきません。
- ゼロ値がある。
var e EmailやEmail{}でコンストラクタを迂回できる - 隠蔽の単位が「型」ではなく「パッケージ」。同じパッケージの中では非公開フィールドに自由に触れる
finalに相当するものがなく、不変性は慣習で守るしかない
つまり、Go で Java 並みの厳密さを型だけで実現しようとすると、どんどん深くなりすぎる。この議論は社内でも実際に起きていて、社内のエンジニアが Go でどこまでカプセル化するか という記事を公開しています。結論は「重要な不変条件を持つ値オブジェクトは型で守る。それ以外は素直に export する。言語が守ってくれないところは規約で守る」でした。
では、他の現場はどこに線を引いているのか。自分たちの答えを共有するだけではなく、来場者の答えを集めに行こう ——それが今回のブースでした。
ブースで用意したもの
3 枚のパネルを用意しました。
① コンテキストの壁をどこで引くか
1 コンテキスト = 1 モジュール / 1 DB スキーマ / 1 コンテナイメージ。DB もコードも、境界づけられたコンテキスト外からは触れない。中は Hexagonal（Ports and Adapters）の形です。
② 付箋を貼るボード「バックエンドでどこまでカプセル化する？」
横軸は 1 本。左から右へ、守り方が「機械」から「人」に移っていきます。
付箋の色は言語です。Go / TypeScript / Java / その他 の 4 色を用意しました。
③ ディップはどこまで守ったか
②と同じ 5 段階の軸に、稼働中リポジトリの実コードと ADR から、ディップの実際の判断を貼りました（後述）。
結果
多くの方から、バックエンドでどこまでカプセル化しているのか考えをいただきました。ありがとうございました！
「lint が弾く」から「テストが落ちる」の間 に多くの意見があります。「型で守る」の左端は 2 枚だけで、しかもどちらも Go ではなく「型！ C#」「型 Rust」。型で言い切れる言語の方が、端に貼ってくれました。右端の「守るのを諦めた」は 1 枚。その手前には「がんばりすぎない」「いい感じにやっただけ」が並びます。
面白かったのは、「レイヤー間の依存関係」が lint 側と規約側の両方に貼られていた ことです。守りたいものは同じで、それを機械に任せるか人に任せるかで位置が変わる。ボードの横軸は、まさにこの差を見るために引いたものでした。
結果としては、Go の付箋は「型で守る」にはほとんど寄らず、lint と CI に集まりました。Go は型で守れる範囲が狭い——これは私たちだけの感覚ではなかったようです
ブースで交わされた会話から
会話の中で繰り返し出てきたのは、実は「どこまでカプセル化するか」の手前の話でした。
DDD を導入したい動きは自分の会社にもある。でも実際にやろうとすると、経営陣や PO との業務・認識のすり合わせや、境界づけられたコンテキストの粒度をどう決めるかで止まってしまう。
「守り方」を選ぶ以前に、「どこで境界を引くか」で詰まっている。これは複数の方から、聞くことができました。もう 1 つ多かったのが「Go で DDD」への関心です。
ディップではこうしています
来場者に聞くだけでは片手落ちなので、ディップの現在地を同じ軸に並べたのがパネル③です。「値と不変条件」「パッケージの可視性」「ドメインの純粋性」「外部リソースとの境界」「サービスとデータの境界」の 5 つについて、Go と Kotlin がそれぞれどの段階で守っているかを、稼働中のコードから起こしました。
自分たちの判断を 4 つに言語化するとこうなります。
- 閉じる単位を、守りたい範囲に合わせて選ぶ
- 型で閉じられないものは、lint で閉じる
- 技術要素ではなく、概念で切る
- 閉じたぶん、何を手放したかを書き残す
軸の上で見ると、こんな配置です。
- 型で守る — 値オブジェクトは、Go なら非公開フィールド＋生成関数、Kotlin ならコンストラクタごと閉じる。ここは両言語とも型で言い切れる
- lint が弾く — Go はここが一番厚い。ドメインへの I/O の import や、トランザクションを経由しない DB アクセスは型では表現できないので、lint で落とす。禁止の理由をエラーメッセージに書いておくので、規約を読まなくても詰まった瞬間に伝わる
- 守るのを諦めた — 大量データの集計判定はドメインに置けない、コンテキストを跨ぐ外部キーは張らない。諦めたものには理由を残し、
nolintも理由なしでは通さない
実際に稼働しているコードを並べてみると、その間に lint とテストという段階があり、Go ではそこが一番厚い。Go は型で守れる範囲が狭い。だから lint を品質チェックではなく、設計の一部として使っている ——これが今回パネルを作って一番はっきりしたことです。
また、ブースで熱があったのは「守り方」ではなく「どこで境界を引くか」の話でした。
ディップではこの部分を、エンジニアと PO が一室に集まって業務を洗い出すイベントストーミングと、AI-DLC で進めています。自分の知らなかった業務を知り、ユビキタス言語を揃えるところから始める。この取り組みは AI-DLCワークショップ体験記：3日間で学んだAI駆動開発の実践と課題 に書いています。
最後に
ブースに立ち寄ってくださった皆さん、付箋を貼ってくださった皆さん、ありがとうございました。「うちはここまで守っている」「ここは諦めた」という話を、また別のカンファレンスでも聞かせてください。
