TypeScript/ドメインサービス設計: ファクトリ関数と関数群の使い分けについて

Question

## 質問ドメイン層のサービス実装において、以下の 2 つのパターンのどちらを採用すべきか判断に迷っています。 ## 現状の 2 つのパターン ### パターン 1: 依存性注入が必要な場合（ファクトリ関数） ``` domain/ └── service.ts ``` ```typescript // domain/service.ts export function createServiceA(database: DatabaseFacade): ServiceA { return { async updateData(id: string, value: boolean): Promise { await database.update(id, value); }, async getData(): Promise { return await database.getAll(); }, }; } ``` ### パターン 2: 依存性注入が不要な場合（関数群） ``` domain/ └── services/ └── processor.ts ``` ```typescript // domain/services/processor.ts export function processData(input: Input[]): Output[] { return input.map((item) => ({ id: item.id, value: transform(item.value), })); } function transform(value: string): string { return value.toUpperCase(); } function validate(input: Input): boolean { return input.id.length > 0; } ``` ## 検討している 2 つの選択肢 ### 選択肢 A: 全部ファクトリ関数で統一 ``` domain/ └── service.ts // すべてのサービスをここに ``` ```typescript // 依存性あり createServiceA(database); // 依存性なし（空の引数でもOK） createProcessorService(); ``` **メリット:** - 統一されたパターンで一貫性がある - 将来的に依存性が追加されても変更が少ない **デメリット:** - 依存性がないのにファクトリ関数にするのは不自然かもしれない - 純粋関数をわざわざオブジェクトに包む必要がある ### 選択肢 B: 依存性の有無で区分 ``` domain/ ├── service.ts // 依存性あり → ファクトリ関数 └── services/ └── processor.ts // 依存性なし → 関数群 ``` ```typescript // 依存性あり → ファクトリ関数 createServiceA(database); // 依存性なし → 関数群 processData(input); ``` **メリット:** - 依存性の有無がコードから明確に分かる - 純粋関数はそのまま関数として定義できてシンプル - 不要な抽象化を避けられる **デメリット:** - パターンが混在する - 将来的に依存性が追加された場合、関数群からファクトリ関数への変更が必要 ## 質問 1. どちらの選択肢がより良い設計だと思いますか？ 2. その判断理由を教えてください。 3. 業界のベストプラクティスやモダンな実装パターンとして、どちらが推奨されますか？ ## 補足情報 - TypeScript と、コンポーネントという概念の入門者です。（JavaScript は書けますが、体系的な知識はありません。）

Accepted Answer

TypeScriptの型は構造(メンバ名の一致)で判断され、同名のメンバ名を持つオブジェクトは同一あるいは部分型とみなされます
```

class A{
  F():number{
    return 1
  }
}

class B{
  F():number{
    return 2
  }
}

const i:A=new B()
console.log(i.F())
```
```
2
```
引数を必須とする関数型指向の設計とは本来反りが合いません
特にオブジェクトを引数に取る関数は可能な限り取り払い、オブジェクトの振る舞いとして提供される形が理想的です

厳格なルール規定とレビュー体制を両立するチーム開発であれば、依存性の明示は関数の実装意図を共有する意味で必要性を伴います

業務であればこれを達成することは前提要件として容易な一方、業務外では過去資産を含めライブラリの管理を煩雑にします

•メンバ名に被り(不要なオーバーライド)はないか
•引数にオブジェクトが正しく渡されているか

すなはち「関数に適用されるクラスの設計は適切か」を最低限意識し、不適切なオブジェクトを引き金とした動作不良に注意を払う必要があります
その労力と可読性のトレードオフをどの程度受容するかでそれぞれのモデルを選択すると良いでしょう

まとめると
•理想形としてAを推奨
•業務面ではBが推奨

となります