@k2works/claude-code-booster 3.4.1 → 3.6.0

package/lib/assets/docs/article/functional-desgin-ppp/all/15-gossiping-bus-drivers.md

@@ -1,156 +1,156 @@
-# 第15章: Gossiping Bus Drivers — 6言語統合ガイド
-
-## 1. はじめに
-
-Gossiping Bus Drivers は、バス運転手たちが停留所で出会うたびに噂を交換し、全員が同じ噂を共有するまでシミュレーションを続ける問題です。関数型プログラミングの**状態遷移**、**集合演算**、**無限シーケンス**を学ぶ格好の題材です。
-
-## 2. 共通の本質
-
-### 問題の構造
-
-1. 各運転手は固定のルートを**循環**する
-2. 同じ停留所にいる運転手同士が**噂を交換**する（集合の和）
-3. 全運転手が**同じ噂の集合**を持ったら終了
-4. 480 ステップ（1 日分）以内に収束しなければ「不可能」
-
-### 核となるアルゴリズム
-
-```
-ループ:
-  1. 各運転手の現在位置を計算（ルートの循環）
-  2. 同じ停留所にいる運転手をグループ化
-  3. 同一グループ内の噂を集合和で統合
-  4. 全員の噂が一致すれば終了
-```
-
-## 3. 言語別実装比較
-
-### 3.1 循環ルートの表現
-
-| 言語 | 実装方法 | 特徴 |
-|------|---------|------|
-| Clojure | `(cycle route)` | 遅延無限シーケンス |
-| Scala | `position % route.length` | 剰余演算 |
-| Elixir | `Stream.cycle(route)` | Stream ベース |
-| F# | `position % route.Length` | 剰余演算 |
-| Haskell | `cycle route` | 遅延無限リスト |
-| Rust | `current_index % stops.len()` | 剰余演算 |
-
-Clojure と Haskell は言語の遅延評価を活かし、`cycle` で無限シーケンスを直接生成します。他の言語は剰余演算で循環を表現します。
-
-<details>
-<summary>Clojure / Haskell: 遅延無限シーケンス</summary>
-
-```clojure
-;; Clojure: 無限列からn番目を取得
-(defn current-stop [driver step]
-  (nth (cycle (:route driver)) step))
-```
-
-```haskell
--- Haskell: cycle で無限リスト
-currentStop :: Driver -> Int -> Stop
-currentStop driver step = cycle (driverRoute driver) !! step
-```
-
-</details>
-
-<details>
-<summary>Rust / Scala: 剰余演算</summary>
-
-```rust
-pub fn current_stop(&self, step: usize) -> &Stop {
-    &self.route.stops[step % self.route.stops.len()]
-}
-```
-
-```scala
-def currentStop(step: Int): Stop =
-  route(step % route.length)
-```
-
-</details>
-
-### 3.2 噂の交換（集合演算）
-
-| 言語 | 集合和の方法 |
-|------|-----------|
-| Clojure | `clojure.set/union` |
-| Scala | `rumors ++ otherRumors` |
-| Elixir | `MapSet.union(a, b)` |
-| F# | `Set.unionMany` |
-| Haskell | `Set.unions` |
-| Rust | `a.union(&b).cloned().collect()` |
-
-<details>
-<summary>噂交換の実装比較</summary>
-
-```clojure
-;; Clojure
-(defn share-rumors [drivers-at-stop]
-  (let [all-rumors (apply set/union (map :rumors drivers-at-stop))]
-    (map #(assoc % :rumors all-rumors) drivers-at-stop)))
-```
-
-```scala
-// Scala
-def shareRumors(drivers: Vector[Driver]): Vector[Driver] =
-  val allRumors = drivers.flatMap(_.rumors).toSet
-  drivers.map(_.copy(rumors = allRumors))
-```
-
-```elixir
-# Elixir
-def share_rumors(drivers) do
-  all_rumors = Enum.reduce(drivers, MapSet.new(), fn d, acc ->
-    MapSet.union(acc, d.rumors)
-  end)
-  Enum.map(drivers, &%{&1 | rumors: all_rumors})
-end
-```
-
-</details>
-
-### 3.3 状態管理のアプローチ
-
-| 言語 | 状態の扱い | 更新方法 |
-|------|----------|---------|
-| Clojure | 不変マップ | 新しいマップを返す |
-| Scala | case class | `copy` で新インスタンス |
-| Elixir | 不変構造体 | `%{struct \| field: value}` |
-| F# | 不変レコード | `{ record with field = value }` |
-| Haskell | 不変レコード | レコード更新構文 |
-| Rust | 可変 + Clone | `clone()` で新インスタンス |
-
-全言語が**不変の状態遷移**を基本とし、各ステップで新しいワールド状態を生成します。
-
-## 4. 比較分析
-
-### 4.1 遅延評価 vs 剰余演算
-
-- **遅延評価**（Clojure, Haskell）: 概念的に美しく、ルートが無限シーケンスとして自然に表現される
-- **剰余演算**（Scala, F#, Rust）: シンプルで効率的、メモリ使用量が予測可能
-
-### 4.2 集合演算の表現力
-
-Clojure と Haskell は集合演算が最も簡潔です。Rust は所有権システムのため `cloned().collect()` が必要になりますが、メモリ安全性が保証されます。
-
-## 5. 実践的な選択指針
-
-| 要件 | 推奨言語 | 理由 |
-|------|---------|------|
-| 概念的な明快さ | Clojure, Haskell | 遅延無限シーケンスが問題の本質に合致 |
-| パフォーマンス | Rust | ゼロコスト抽象化と所有権管理 |
-| 並行シミュレーション | Elixir | BEAM VM の並行処理が自然に拡張可能 |
-
-## 6. まとめ
-
-Gossiping Bus Drivers は、関数型プログラミングの 3 つの要素を統合的に学べる問題です：
-
-1. **循環データ**: 遅延シーケンス or 剰余演算
-2. **集合演算**: 噂の伝播は集合の和
-3. **状態遷移**: 各ステップが純粋関数
-
-## 言語別個別記事
-
-- [Clojure](../clojure/15-gossiping-bus-drivers.md) | [Scala](../scala/15-gossiping-bus-drivers.md) | [Elixir](../elixir/15-gossiping-bus-drivers.md) | [F#](../fsharp/15-gossiping-bus-drivers.md) | [Haskell](../haskell/15-gossiping-bus-drivers.md) | [Rust](../rust/15-gossiping-bus-drivers.md)
+# 第15章: Gossiping Bus Drivers — 6言語統合ガイド
+
+## 1. はじめに
+
+Gossiping Bus Drivers は、バス運転手たちが停留所で出会うたびに噂を交換し、全員が同じ噂を共有するまでシミュレーションを続ける問題です。関数型プログラミングの**状態遷移**、**集合演算**、**無限シーケンス**を学ぶ格好の題材です。
+
+## 2. 共通の本質
+
+### 問題の構造
+
+1. 各運転手は固定のルートを**循環**する
+2. 同じ停留所にいる運転手同士が**噂を交換**する（集合の和）
+3. 全運転手が**同じ噂の集合**を持ったら終了
+4. 480 ステップ（1 日分）以内に収束しなければ「不可能」
+
+### 核となるアルゴリズム
+
+```
+ループ:
+  1. 各運転手の現在位置を計算（ルートの循環）
+  2. 同じ停留所にいる運転手をグループ化
+  3. 同一グループ内の噂を集合和で統合
+  4. 全員の噂が一致すれば終了
+```
+
+## 3. 言語別実装比較
+
+### 3.1 循環ルートの表現
+
+| 言語 | 実装方法 | 特徴 |
+|------|---------|------|
+| Clojure | `(cycle route)` | 遅延無限シーケンス |
+| Scala | `position % route.length` | 剰余演算 |
+| Elixir | `Stream.cycle(route)` | Stream ベース |
+| F# | `position % route.Length` | 剰余演算 |
+| Haskell | `cycle route` | 遅延無限リスト |
+| Rust | `current_index % stops.len()` | 剰余演算 |
+
+Clojure と Haskell は言語の遅延評価を活かし、`cycle` で無限シーケンスを直接生成します。他の言語は剰余演算で循環を表現します。
+
+<details>
+<summary>Clojure / Haskell: 遅延無限シーケンス</summary>
+
+```clojure
+;; Clojure: 無限列からn番目を取得
+(defn current-stop [driver step]
+  (nth (cycle (:route driver)) step))
+```
+
+```haskell
+-- Haskell: cycle で無限リスト
+currentStop :: Driver -> Int -> Stop
+currentStop driver step = cycle (driverRoute driver) !! step
+```
+
+</details>
+
+<details>
+<summary>Rust / Scala: 剰余演算</summary>
+
+```rust
+pub fn current_stop(&self, step: usize) -> &Stop {
+    &self.route.stops[step % self.route.stops.len()]
+}
+```
+
+```scala
+def currentStop(step: Int): Stop =
+  route(step % route.length)
+```
+
+</details>
+
+### 3.2 噂の交換（集合演算）
+
+| 言語 | 集合和の方法 |
+|------|-----------|
+| Clojure | `clojure.set/union` |
+| Scala | `rumors ++ otherRumors` |
+| Elixir | `MapSet.union(a, b)` |
+| F# | `Set.unionMany` |
+| Haskell | `Set.unions` |
+| Rust | `a.union(&b).cloned().collect()` |
+
+<details>
+<summary>噂交換の実装比較</summary>
+
+```clojure
+;; Clojure
+(defn share-rumors [drivers-at-stop]
+  (let [all-rumors (apply set/union (map :rumors drivers-at-stop))]
+    (map #(assoc % :rumors all-rumors) drivers-at-stop)))
+```
+
+```scala
+// Scala
+def shareRumors(drivers: Vector[Driver]): Vector[Driver] =
+  val allRumors = drivers.flatMap(_.rumors).toSet
+  drivers.map(_.copy(rumors = allRumors))
+```
+
+```elixir
+# Elixir
+def share_rumors(drivers) do
+  all_rumors = Enum.reduce(drivers, MapSet.new(), fn d, acc ->
+    MapSet.union(acc, d.rumors)
+  end)
+  Enum.map(drivers, &%{&1 | rumors: all_rumors})
+end
+```
+
+</details>
+
+### 3.3 状態管理のアプローチ
+
+| 言語 | 状態の扱い | 更新方法 |
+|------|----------|---------|
+| Clojure | 不変マップ | 新しいマップを返す |
+| Scala | case class | `copy` で新インスタンス |
+| Elixir | 不変構造体 | `%{struct \| field: value}` |
+| F# | 不変レコード | `{ record with field = value }` |
+| Haskell | 不変レコード | レコード更新構文 |
+| Rust | 可変 + Clone | `clone()` で新インスタンス |
+
+全言語が**不変の状態遷移**を基本とし、各ステップで新しいワールド状態を生成します。
+
+## 4. 比較分析
+
+### 4.1 遅延評価 vs 剰余演算
+
+- **遅延評価**（Clojure, Haskell）: 概念的に美しく、ルートが無限シーケンスとして自然に表現される
+- **剰余演算**（Scala, F#, Rust）: シンプルで効率的、メモリ使用量が予測可能
+
+### 4.2 集合演算の表現力
+
+Clojure と Haskell は集合演算が最も簡潔です。Rust は所有権システムのため `cloned().collect()` が必要になりますが、メモリ安全性が保証されます。
+
+## 5. 実践的な選択指針
+
+| 要件 | 推奨言語 | 理由 |
+|------|---------|------|
+| 概念的な明快さ | Clojure, Haskell | 遅延無限シーケンスが問題の本質に合致 |
+| パフォーマンス | Rust | ゼロコスト抽象化と所有権管理 |
+| 並行シミュレーション | Elixir | BEAM VM の並行処理が自然に拡張可能 |
+
+## 6. まとめ
+
+Gossiping Bus Drivers は、関数型プログラミングの 3 つの要素を統合的に学べる問題です：
+
+1. **循環データ**: 遅延シーケンス or 剰余演算
+2. **集合演算**: 噂の伝播は集合の和
+3. **状態遷移**: 各ステップが純粋関数
+
+## 言語別個別記事
+
+- [Clojure](../clojure/15-gossiping-bus-drivers.md) | [Scala](../scala/15-gossiping-bus-drivers.md) | [Elixir](../elixir/15-gossiping-bus-drivers.md) | [F#](../fsharp/15-gossiping-bus-drivers.md) | [Haskell](../haskell/15-gossiping-bus-drivers.md) | [Rust](../rust/15-gossiping-bus-drivers.md)

package/lib/assets/docs/article/functional-desgin-ppp/all/16-payroll-system.md

@@ -1,178 +1,178 @@
-# 第16章: 給与計算システム — 6言語統合ガイド
-
-## 1. はじめに
-
-給与計算システムは、**ドメインモデリング**と**多態的ディスパッチ**を実践的に学ぶためのケーススタディです。従業員の種類（時給制・月給制・歩合制）に応じた給与計算ロジックを、関数型パラダイムでどう設計するかを比較します。
-
-## 2. 共通の本質
-
-### ドメインモデル
-
-すべての言語で共通のドメイン概念：
-
-- **従業員分類**: 時給制（Hourly）、月給制（Salaried）、歩合制（Commissioned）
-- **支払いスケジュール**: 週次、月次、隔週
-- **支払い方法**: 銀行振込、小切手、手渡し
-- **計算ルール**: 残業（40 時間超）、歩合率、固定給
-
-### 計算ロジック
-
-```
-時給制:   通常時間 × 時給 + 残業時間 × 時給 × 1.5
-月給制:   固定月給
-歩合制:   基本給 + 売上 × 歩合率
-```
-
-## 3. 言語別実装比較
-
-### 3.1 従業員分類の型表現
-
-| 言語 | 型表現 | 多態性の方法 |
-|------|--------|-----------|
-| Clojure | マップ + キーワード | `defmulti` でディスパッチ |
-| Scala | `sealed trait` + `case class` | パターンマッチング |
-| Elixir | 構造体 + タプルタグ | パターンマッチング |
-| F# | 判別共用体 | パターンマッチング |
-| Haskell | 代数的データ型 | case 式 |
-| Rust | `enum` | `match` 式 |
-
-<details>
-<summary>Clojure: マップ + マルチメソッド</summary>
-
-```clojure
-(defmulti calculate-pay :pay-type)
-
-(defmethod calculate-pay :hourly [{:keys [hours hourly-rate]}]
-  (let [regular (min hours 40)
-        overtime (max 0 (- hours 40))]
-    (+ (* regular hourly-rate)
-       (* overtime hourly-rate 1.5))))
-
-(defmethod calculate-pay :salaried [{:keys [monthly-salary]}]
-  monthly-salary)
-
-(defmethod calculate-pay :commissioned [{:keys [base-salary sales commission-rate]}]
-  (+ base-salary (* sales commission-rate)))
-```
-
-</details>
-
-<details>
-<summary>Scala: sealed trait + パターンマッチ</summary>
-
-```scala
-sealed trait PayClassification
-case class Hourly(hourlyRate: Double) extends PayClassification
-case class Salaried(monthlySalary: Double) extends PayClassification
-case class Commissioned(baseSalary: Double, commissionRate: Double) extends PayClassification
-
-def calculatePay(classification: PayClassification, hours: Double, sales: Double): Double =
-  classification match
-    case Hourly(rate) =>
-      val regular = math.min(hours, 40)
-      val overtime = math.max(0, hours - 40)
-      regular * rate + overtime * rate * 1.5
-    case Salaried(salary) => salary
-    case Commissioned(base, rate) => base + sales * rate
-```
-
-</details>
-
-<details>
-<summary>Haskell: ADT + case 式</summary>
-
-```haskell
-data PayClassification
-    = Hourly Double
-    | Salaried Double
-    | Commissioned Double Double
-
-calculatePay :: PayClassification -> Double -> Double -> Double
-calculatePay classification hours sales = case classification of
-    Hourly rate ->
-        let regular = min hours 40
-            overtime = max 0 (hours - 40)
-        in regular * rate + overtime * rate * 1.5
-    Salaried salary -> salary
-    Commissioned base rate -> base + sales * rate
-```
-
-</details>
-
-<details>
-<summary>Rust: enum + match</summary>
-
-```rust
-pub enum PayClassification {
-    Hourly { hourly_rate: f64 },
-    Salaried { monthly_salary: f64 },
-    Commissioned { base_salary: f64, commission_rate: f64 },
-}
-
-impl PayClassification {
-    pub fn calculate(&self, hours: f64, sales: f64) -> f64 {
-        match self {
-            Self::Hourly { hourly_rate } => {
-                let regular = hours.min(40.0);
-                let overtime = (hours - 40.0).max(0.0);
-                regular * hourly_rate + overtime * hourly_rate * 1.5
-            }
-            Self::Salaried { monthly_salary } => *monthly_salary,
-            Self::Commissioned { base_salary, commission_rate } => {
-                base_salary + sales * commission_rate
-            }
-        }
-    }
-}
-```
-
-</details>
-
-### 3.2 データモデルの設計哲学
-
-| 言語 | 設計哲学 | データ定義 |
-|------|---------|----------|
-| Clojure | データ駆動 | マップリテラル、スキーマは Spec で後付け |
-| Scala | 型駆動 | case class 階層、コンパイル時チェック |
-| Elixir | データ駆動 | 構造体、タプルタグで分類 |
-| F# | 型駆動 | 判別共用体、コンパイル時網羅性チェック |
-| Haskell | 型駆動 | ADT、最も厳密な型チェック |
-| Rust | 型駆動 | enum、所有権 + 型安全性 |
-
-**動的型付け言語**（Clojure, Elixir）はデータ構造が柔軟で、新しいフィールドの追加が容易です。**静的型付け言語**（Scala, F#, Haskell, Rust）はコンパイル時にドメインルールの整合性を保証します。
-
-### 3.3 拡張性の違い
-
-新しい従業員分類（例: 日給制）を追加する場合：
-
-| 言語 | 変更箇所 | 安全性 |
-|------|---------|--------|
-| Clojure | `defmethod` を 1 つ追加 | テストで確認 |
-| Scala | case class 追加 + match に追加 | コンパイルエラーで検出 |
-| Elixir | 関数クローズを追加 | テストで確認 |
-| F# | 判別共用体に追加 + match に追加 | コンパイルエラーで検出 |
-| Haskell | ADT に追加 + case に追加 | コンパイルエラーで検出 |
-| Rust | enum に追加 + match に追加 | コンパイルエラーで検出 |
-
-## 4. 比較分析
-
-### ドメインモデリングのトレードオフ
-
-| 基準 | 動的型付け（Clojure, Elixir） | 静的型付け（Scala, F#, Haskell, Rust） |
-|------|---------------------------|-----------------------------------|
-| 柔軟性 | 高い（スキーマレス） | 型定義が必要 |
-| 安全性 | テストに依存 | コンパイル時チェック |
-| リファクタリング | リスクあり | コンパイラが支援 |
-| プロトタイピング | 高速 | 型設計が必要 |
-
-## 5. まとめ
-
-給与計算システムは、関数型言語でのドメインモデリングの典型例です：
-
-1. **多態的ディスパッチ**: 従業員分類ごとの計算を言語の多態性で表現
-2. **データと処理の分離**: データ定義と計算ロジックを明確に分離
-3. **拡張性**: 新しい分類の追加が既存コードへの影響を最小化
-
-## 言語別個別記事
-
-- [Clojure](../clojure/16-payroll-system.md) | [Scala](../scala/16-payroll-system.md) | [Elixir](../elixir/16-payroll-system.md) | [F#](../fsharp/16-payroll-system.md) | [Haskell](../haskell/16-payroll-system.md) | [Rust](../rust/16-payroll-system.md)
+# 第16章: 給与計算システム — 6言語統合ガイド
+
+## 1. はじめに
+
+給与計算システムは、**ドメインモデリング**と**多態的ディスパッチ**を実践的に学ぶためのケーススタディです。従業員の種類（時給制・月給制・歩合制）に応じた給与計算ロジックを、関数型パラダイムでどう設計するかを比較します。
+
+## 2. 共通の本質
+
+### ドメインモデル
+
+すべての言語で共通のドメイン概念：
+
+- **従業員分類**: 時給制（Hourly）、月給制（Salaried）、歩合制（Commissioned）
+- **支払いスケジュール**: 週次、月次、隔週
+- **支払い方法**: 銀行振込、小切手、手渡し
+- **計算ルール**: 残業（40 時間超）、歩合率、固定給
+
+### 計算ロジック
+
+```
+時給制:   通常時間 × 時給 + 残業時間 × 時給 × 1.5
+月給制:   固定月給
+歩合制:   基本給 + 売上 × 歩合率
+```
+
+## 3. 言語別実装比較
+
+### 3.1 従業員分類の型表現
+
+| 言語 | 型表現 | 多態性の方法 |
+|------|--------|-----------|
+| Clojure | マップ + キーワード | `defmulti` でディスパッチ |
+| Scala | `sealed trait` + `case class` | パターンマッチング |
+| Elixir | 構造体 + タプルタグ | パターンマッチング |
+| F# | 判別共用体 | パターンマッチング |
+| Haskell | 代数的データ型 | case 式 |
+| Rust | `enum` | `match` 式 |
+
+<details>
+<summary>Clojure: マップ + マルチメソッド</summary>
+
+```clojure
+(defmulti calculate-pay :pay-type)
+
+(defmethod calculate-pay :hourly [{:keys [hours hourly-rate]}]
+  (let [regular (min hours 40)
+        overtime (max 0 (- hours 40))]
+    (+ (* regular hourly-rate)
+       (* overtime hourly-rate 1.5))))
+
+(defmethod calculate-pay :salaried [{:keys [monthly-salary]}]
+  monthly-salary)
+
+(defmethod calculate-pay :commissioned [{:keys [base-salary sales commission-rate]}]
+  (+ base-salary (* sales commission-rate)))
+```
+
+</details>
+
+<details>
+<summary>Scala: sealed trait + パターンマッチ</summary>
+
+```scala
+sealed trait PayClassification
+case class Hourly(hourlyRate: Double) extends PayClassification
+case class Salaried(monthlySalary: Double) extends PayClassification
+case class Commissioned(baseSalary: Double, commissionRate: Double) extends PayClassification
+
+def calculatePay(classification: PayClassification, hours: Double, sales: Double): Double =
+  classification match
+    case Hourly(rate) =>
+      val regular = math.min(hours, 40)
+      val overtime = math.max(0, hours - 40)
+      regular * rate + overtime * rate * 1.5
+    case Salaried(salary) => salary
+    case Commissioned(base, rate) => base + sales * rate
+```
+
+</details>
+
+<details>
+<summary>Haskell: ADT + case 式</summary>
+
+```haskell
+data PayClassification
+    = Hourly Double
+    | Salaried Double
+    | Commissioned Double Double
+
+calculatePay :: PayClassification -> Double -> Double -> Double
+calculatePay classification hours sales = case classification of
+    Hourly rate ->
+        let regular = min hours 40
+            overtime = max 0 (hours - 40)
+        in regular * rate + overtime * rate * 1.5
+    Salaried salary -> salary
+    Commissioned base rate -> base + sales * rate
+```
+
+</details>
+
+<details>
+<summary>Rust: enum + match</summary>
+
+```rust
+pub enum PayClassification {
+    Hourly { hourly_rate: f64 },
+    Salaried { monthly_salary: f64 },
+    Commissioned { base_salary: f64, commission_rate: f64 },
+}
+
+impl PayClassification {
+    pub fn calculate(&self, hours: f64, sales: f64) -> f64 {
+        match self {
+            Self::Hourly { hourly_rate } => {
+                let regular = hours.min(40.0);
+                let overtime = (hours - 40.0).max(0.0);
+                regular * hourly_rate + overtime * hourly_rate * 1.5
+            }
+            Self::Salaried { monthly_salary } => *monthly_salary,
+            Self::Commissioned { base_salary, commission_rate } => {
+                base_salary + sales * commission_rate
+            }
+        }
+    }
+}
+```
+
+</details>
+
+### 3.2 データモデルの設計哲学
+
+| 言語 | 設計哲学 | データ定義 |
+|------|---------|----------|
+| Clojure | データ駆動 | マップリテラル、スキーマは Spec で後付け |
+| Scala | 型駆動 | case class 階層、コンパイル時チェック |
+| Elixir | データ駆動 | 構造体、タプルタグで分類 |
+| F# | 型駆動 | 判別共用体、コンパイル時網羅性チェック |
+| Haskell | 型駆動 | ADT、最も厳密な型チェック |
+| Rust | 型駆動 | enum、所有権 + 型安全性 |
+
+**動的型付け言語**（Clojure, Elixir）はデータ構造が柔軟で、新しいフィールドの追加が容易です。**静的型付け言語**（Scala, F#, Haskell, Rust）はコンパイル時にドメインルールの整合性を保証します。
+
+### 3.3 拡張性の違い
+
+新しい従業員分類（例: 日給制）を追加する場合：
+
+| 言語 | 変更箇所 | 安全性 |
+|------|---------|--------|
+| Clojure | `defmethod` を 1 つ追加 | テストで確認 |
+| Scala | case class 追加 + match に追加 | コンパイルエラーで検出 |
+| Elixir | 関数クローズを追加 | テストで確認 |
+| F# | 判別共用体に追加 + match に追加 | コンパイルエラーで検出 |
+| Haskell | ADT に追加 + case に追加 | コンパイルエラーで検出 |
+| Rust | enum に追加 + match に追加 | コンパイルエラーで検出 |
+
+## 4. 比較分析
+
+### ドメインモデリングのトレードオフ
+
+| 基準 | 動的型付け（Clojure, Elixir） | 静的型付け（Scala, F#, Haskell, Rust） |
+|------|---------------------------|-----------------------------------|
+| 柔軟性 | 高い（スキーマレス） | 型定義が必要 |
+| 安全性 | テストに依存 | コンパイル時チェック |
+| リファクタリング | リスクあり | コンパイラが支援 |
+| プロトタイピング | 高速 | 型設計が必要 |
+
+## 5. まとめ
+
+給与計算システムは、関数型言語でのドメインモデリングの典型例です：
+
+1. **多態的ディスパッチ**: 従業員分類ごとの計算を言語の多態性で表現
+2. **データと処理の分離**: データ定義と計算ロジックを明確に分離
+3. **拡張性**: 新しい分類の追加が既存コードへの影響を最小化
+
+## 言語別個別記事
+
+- [Clojure](../clojure/16-payroll-system.md) | [Scala](../scala/16-payroll-system.md) | [Elixir](../elixir/16-payroll-system.md) | [F#](../fsharp/16-payroll-system.md) | [Haskell](../haskell/16-payroll-system.md) | [Rust](../rust/16-payroll-system.md)