COMをF#のドメインAPIへ — Option・Result・状態を境界で扱う

結論

ベンダー固有の状態と失敗を型に変換し、呼び出し側の暗黙の前提を減らす。

背景

COMの可変状態、null、例外を呼び出し側へそのまま渡すと、アプリケーションの各所がベンダーの振る舞いを知る必要が生じる。変換責任をアダプターへ集める。

設計と検証の論点

構成を検討するときは、次の責任と境界を分けて確認します。

• COMとの相互運用
• null許容値
• 状態を持つAPI
• 判別共用体
• Option・Result
• ドメイン型
• リソースの生存期間

価格を非負とするドメインでは、欠損と不正な値を次のように別の型で表せる。これは変換境界の最小例であり、COMの生成・解放やスレッド制約は別に扱う。

open System

type Price = private Price of decimal

type ConversionError =
    | MissingValue
    | InvalidPrice of decimal

let toPrice (value: Nullable<decimal>) =
    if not value.HasValue then Error MissingValue
    elif value.Value < 0m then Error (InvalidPrice value.Value)
    else Ok (Price value.Value)

判断理由

COMとの相互運用とリソースの生存期間の関係を軸に、採用案と代替案の責任範囲を比較します。既存の制約を残す理由と、新しい境界で変えられることを分けて記述します。

トレードオフ

null許容値を扱うために増える実装・保守・確認作業と、得られる制御可能性を比較します。障害時の経路と運用担当者の負担を含め、採用しない方がよい条件も示します。

制約

型による変換だけでは、COMのスレッド制約やリソース寿命は解消しない。呼び出しスレッド、解放処理、エラー分類を別に設計する必要がある。先行ラッパーの著作者と利用条件も再利用の前提となる。

関連事例

• レガシーAPIのモダナイゼーション

関連事例の担当範囲や設計判断を参照します。記事で提案する実験・構成を、その事例で実施済みとするものではありません。