はじめに
ブラジル出身のエンジニアです。日本に3年以上住み、日本の開発チームでも働きました。
日本の生活で一番印象に残ったのは、整理されていること、毎日同じ品質が続くこと、そしてルールがみんなに守られていることでした。
最初は戸惑うことも多かったのですが、あるとき気づきました。
「これ、DDDやTDDで大切にしている考え方と同じだ」と。
この記事では、日本の生活で学んだ5つのことを、DDDとTDDの実践に結びつけて紹介します。
1. ゴミの分別 → レイヤーの分離
群馬県の前橋市に引っ越してすぐ、最初に渡されたものの一つがゴミ袋でした。
まだ日本語も生活のルールもよく分からない私に、「ゴミはこの袋に入れて出してください」と、最初から正しい道具が用意されていたのです。
そのあと、燃えるゴミ、プラスチック、資源ゴミ…と、種類ごとに出す場所も曜日も決まっていることを知り、最初は正直とても戸惑いました。
でも生活していくうちに、**「すべてのものに正しい置き場所があり、そのための仕組みが最初から用意されている」**からこそ、街全体がきれいに保たれているのだと気づきました。
コードも同じです。ビジネスルールとDBアクセスとUIが同じファイルに混ざっていると、どこを直せばいいのか分からなくなります。
src/
├── domain/ # ビジネスルール(一番大切なもの)
├── application/ # ユースケース(何をするか)
├── infrastructure/ # DB・外部API(どうやって保存・通信するか)
└── presentation/ # 画面・APIのエンドポイント
ルールはシンプルです。
-
domainは他のどのレイヤーにも依存しない - DBやフレームワークの都合を
domainに持ち込まない
ゴミを間違った日に出すと回収されないように、間違った場所に置かれたコードは、いつか必ず問題になります。
2. ポカヨケ → Value Object
ポカヨケは、日本の製造現場で生まれた「そもそもミスが起きない仕組みを作る」という考え方です。
USBが逆向きに挿さらない形になっているのも、その一例です。
DDDの Value Object は、まさにコードのポカヨケです。
不正な値を持ったオブジェクトを、そもそも作れないようにします。
export class PostalCode {
private constructor(private readonly value: string) {}
static create(input: string): PostalCode {
const normalized = input.replace(/-/g, '');
if (!/^\d{7}$/.test(normalized)) {
throw new Error('郵便番号は7桁の数字で入力してください');
}
return new PostalCode(normalized);
}
format(): string {
return `${this.value.slice(0, 3)}-${this.value.slice(3)}`;
}
equals(other: PostalCode): boolean {
return this.value === other.value;
}
}
string のままだと、どこでどんな値が入るか分かりません。
PostalCode 型にすれば、この型の値がある時点で 「正しい郵便番号であること」が保証されます。
チェック処理をあちこちに書く必要もなくなります。
3. 電車の定時運行 → TDDのリズム
日本の電車は、毎日ほぼ時刻表どおりに来ます。
これは特別な才能ではなく、決まった手順を毎日くり返す仕組みがあるからだと思います。
TDDにも、決まったリズムがあります。
- Red:まず失敗するテストを書く
- Green:テストが通る最小限のコードを書く
- Refactor:動く状態を保ったまま、コードをきれいにする
先ほどの PostalCode も、実はテストから書きました。
import { PostalCode } from './PostalCode';
describe('PostalCode', () => {
it('7桁の数字から作成できる', () => {
const postalCode = PostalCode.create('1500001');
expect(postalCode.format()).toBe('150-0001');
});
it('ハイフン付きの入力でも作成できる', () => {
const postalCode = PostalCode.create('150-0001');
expect(postalCode.format()).toBe('150-0001');
});
it('6桁の場合はエラーになる', () => {
expect(() => PostalCode.create('150000')).toThrow();
});
it('数字以外が含まれる場合はエラーになる', () => {
expect(() => PostalCode.create('150-000A')).toThrow();
});
});
大切なのは、大きな変更を一気にやらないことです。
小さなサイクルを毎日くり返すことで、品質が安定します。電車の定時運行と同じです。
4. 改善(カイゼン) → Refactor
日本の職場では「改善」という言葉をよく聞きました。
一度に大きく変えるのではなく、毎日少しずつ良くしていくという考え方です。
TDDの Refactor ステップは、まさに改善です。
テストがあるから、安心して少しずつコードを良くできます。
// Before:意味の分からない数字
if (items.length > 5) { ... }
// After:ルールに名前をつける
const MAX_ITEMS_PER_ORDER = 5;
if (items.length > MAX_ITEMS_PER_ORDER) { ... }
小さな変更ですが、こうした改善を積み重ねると、半年後のコードの読みやすさが大きく変わります。
5. 統一された標識 → ユビキタス言語
日本の駅は、どこへ行っても標識の形・色・言葉が統一されていて、初めての駅でも迷いにくいです。
DDDの ユビキタス言語 も同じ考え方です。
ビジネスの会話・ドキュメント・コード・DBで、同じものには同じ名前を使います。
| 会話 | コード | 問題 |
|---|---|---|
| 「予約」 |
Booking / Reservation / Appointment が混在 |
どれが同じものか分からない |
| 「予約」 | すべて Reservation
|
誰が見ても迷わない |
名前がぶれると、チームの理解もぶれます。
標識が統一されている駅のように、誰が読んでも迷わないコードを目指しましょう。
まとめ
| 日本の生活 | 開発での実践 |
|---|---|
| ゴミの分別 | レイヤーの分離 |
| ポカヨケ | Value Object |
| 電車の定時運行 | TDDのリズム |
| 改善 | Refactor |
| 統一された標識 | ユビキタス言語 |
DDDやTDDは、難しい理論のように見えるかもしれません。
でも根っこにあるのは、日本の生活の中にある 「整理する」「続ける」「ルールを守る」 という、とてもシンプルな考え方だと思います。
日本で学んだこの感覚は、ブラジルに戻った今も、毎日のコードの中で生きています。
読んでいただき、ありがとうございました!