概要

「ユーティリティ関数（utility）」は、よく使う処理を再利用可能にまとめるという発想に基づくが、
無差別に再利用可能にすることが目的ではない。

それは**“汎用性と責務を適切にバランスさせ、ドメインロジックと分離することでアプリケーションの一貫性を支える構造”**である。

本稿では、ユーティリティ関数の設計原則、ドメイン層との分離基準、命名・引数設計・テスト容易性の観点からの最適化戦略を解説する。

1. ユーティリティ関数とは

✅ 汎用性が高く、アプリケーション全体で再利用可能
✅ 状態を持たず、純粋関数であることが原則
✅ ドメイン（業務）知識に依存しない、技術的/構文的処理

export function capitalize(str) {
  return str.charAt(0).toUpperCase() + str.slice(1);
}

2. ドメイン関数との分離

// ユーティリティ関数（純粋・再利用可）
export function padZero(num, length = 2) {
  return num.toString().padStart(length, '0');
}

// ドメイン関数（ビジネスルールあり）
export function formatInvoiceId(id) {
  return `INV-${padZero(id)}`;
}

✅ 汎用関数はドメイン知識から隔離
✅ ビジネスルールはアプリ層で閉じる

3. 汎用性の設計判断

判定基準	内容
入力と出力が単純か？	引数・戻り値が明確で、副作用がないか
状態や依存に左右されないか？	内部で外部関数やグローバル参照がないか
ビジネス文脈に依存していないか？	アプリケーションの文脈外でも使えるか

4. 命名規則と責務の粒度設計

// ✅ 良い命名
parseDate()     // パースする
formatCurrency() // 整形する
toSlug()         // 変換する

// ❌ 曖昧な命名
handleStuff()
processThing()

✅ 動詞 + オブジェクト形式で意図を明確に
✅ 責務は1つに → isEmpty() と isBlank() を同居させない

5. テスト容易性と構造

// utils/date.ts
export function getWeekDay(date) {
  return ['Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat'][date.getDay()];
}

test('getWeekDay returns correct abbreviation', () => {
  expect(getWeekDay(new Date('2023-05-14'))).toBe('Sun');
});

✅ グローバル状態に依存せず、完全にピュアな関数であること
✅ 構文・ユースケースの境界に立つよう設計

設計判断フロー

① 関数はドメイン知識に依存していないか？ → ユーティリティへ分離可

② 状態や副作用は含まれていないか？ → 純粋関数に限定

③ 再利用性と読みやすさのバランスは取れているか？ → 命名で意図明示

④ 他のモジュールへの依存があるか？ → 依存を排除または注入に切り替える

⑤ 処理の粒度は細かすぎず、適切か？ → 役割ごとに関数を分割 or 集約

よくあるミスと対策

❌ `utils.js` に全てを詰め込んで1000行以上の肥大化

→ ✅ 機能単位でモジュールを分割（utils/date.ts, utils/math.tsなど）

❌ 関数内でDOMやlocalStorageを操作しており純粋性を失っている

→ ✅ 副作用は外部で処理し、ユーティリティ関数は値変換に徹する

❌ ドメインロジックを抽象化しすぎて意味が不明瞭に

→ ✅ 「誰が使うのか」「何をするのか」が明確な名前と構造に修正

結語

ユーティリティ関数とは、「どこでも使える便利な関数」ではない。
それは**“汎用性と責務の分離を通して、再利用性と設計一貫性を担保する構造要素”**である。

ドメイン知識から分離し、純粋性と独立性を保つ
汎用性の名のもとに責務を曖昧にしない
テスト容易性と意図の明示が、設計としての完成度を高める

JavaScriptにおけるユーティリティ設計とは、
“再利用可能な構文を責任ある形で抽出し、設計の秩序と整合性を維持するための戦略である。”