概要
ユーティリティ関数とは「よく使う処理」ではない。
それは**“本質的ではない処理をドメインロジックから追い出し、構造を純粋に保つための抽象”**である。
JavaScriptの開発において、形式変換・日付操作・バリデーション・文字列整形などは本質とは異なるが必須の処理である。
これらを適切にユーティリティ関数として設計・整理することで、ロジックの見通し・再利用性・テスト性が劇的に向上する。
1. ユーティリティ関数の設計原則
✅ 「再利用される」ではなく「再利用可能である」ことが前提
- 依存がない（ピュア関数）
- 構造が小さい（1つの責務）
- 意味が明確（名前で処理内容が分かる）
function toUpperCaseFirst(str) {
return str.charAt(0).toUpperCase() + str.slice(1);
}
2. 関数の抽出単位は「意味 + 頻度 + 汚れ」
✅ 以下の3条件で抽出判断：
① 意味が共通で汎用的
② 頻度が高い or 重要な流れを支える
③ ドメイン外の処理（＝ロジックのノイズ）
// 抽出すべき例
function formatDate(date) {
return date.toISOString().split('T')[0];
}
3. ユーティリティ vs ドメインロジックの分離
❌ ドメイン層に日付の整形や文字列操作が散在
✅ ユーティリティに抽出してロジックは “業務の意味” だけに集中
// ドメイン層
const label = `契約日: ${formatDate(user.contractAt)}`;
4. ユーティリティ階層と分類
utils/
├─ date.ts → 日付操作
├─ string.ts → 文字列整形
├─ number.ts → 桁区切りや丸め
├─ array.ts → フィルタ・グループ処理
├─ validation.ts → 汎用バリデーション
- ✅ 領域別の抽象に整理
- ✅ index.tsで集約エクスポートすればimportも簡潔に
5. ユーティリティの過剰抽象を避ける
❌ 汎用性を追いすぎて意味が消える
function doSomethingToList(list, fn) {
return list.map(fn);
}
→ ✅ 意味ある用途に絞る方が保守性が高い
6. テスト性とユニット性の最大化
- ✅ ユーティリティ関数は最もテストしやすい領域
- ✅ 入出力が固定化されており副作用ゼロが理想
test('toUpperCaseFirst', () => {
expect(toUpperCaseFirst('hello')).toBe('Hello');
});
設計判断フロー
① 処理はドメインロジックの一部か？ → 汎用ならユーティリティへ
② 関数は再利用可能な構造か？ → 外部依存があれば再設計
③ 意味が明確か？ → 名前と内容が一致しているかを確認
④ 処理を変更する頻度と影響範囲は？ → 共通化が過剰でないか判断
⑤ テストがしやすいか？ → 副作用・非同期・状態依存がないかを確認
よくあるミスと対策
❌ ドメイン層で文字列整形・日付変換を毎回書く
→ ✅ utils/ に抽出し、業務ロジックに集中
❌ 関数名が抽象的すぎて目的が不明
→ ✅ formatDate, padZero, groupBy など用途が明確な名前にする
❌ utils関数がアプリ固有の依存を持って再利用不能
→ ✅ 引数と戻り値のみで完結する設計に限定
結語
ユーティリティとは「便利な関数」ではない。
それは**“ノイズを外に逃がし、本質を見通すための構造戦略”**である。
- ドメインから汚れを抽出し
- 領域ごとに整理し
- 再利用可能で安全に保ち
- テストしやすく設計する
JavaScriptにおけるユーティリティ設計とは、
“ロジックを純化し、構造を美しく保つための補助層のデザイン”である。