フィンテック・エンジニアリング・ハンドブック

フィンテック・エンジニアリング・ハンドブックへようこそ。この資料は、お金がシステムの主要な焦点となるソフトウェアエンジニアリングで使用される最も重要なパターンを説明することを目的としています。包括的な理解を得るために全文を読むことも、特定の問題に対処する際に部分的に読むこともできます。 誰のためか？ フィンテックに加わる人々。ドメインと、お金のシステムを信頼できるものにするパターンに慣れるため。 既にフィンテックにいる人々。特定の問題に直面したときに参照するリファレンスとして、また同僚に指摘するための共通の語彙として。 フィンテック以外の人々。お金のために構築することが、彼らが慣れているものとどのように異なり、その理由を理解するため。 これは生きたドキュメントとして意図されており、貢献を歓迎します。 原則 以下に読むことはすべて、次の3つの原則を遵守する方法です。 データを作り出さない。お金はどこからともなく創造されることはありません。したがって、重複や恣意的な残高更新は許容できません。これを冪等性、重複排除、および照合によって強制します。 データを失わない。お金に起こるすべては追跡され、永続化されなければなりません。これを完全な精度、少なくとも一度の配信、イベントソーシング、監査証跡、および不変性によって保護します。 信頼しない。外部プロバイダー、内部コンポーネント、および世界を信頼しないでください。これをウェブフックの検証、複数のソースにわたるデータの相互確認、および壊れた前提での大音量の失敗によって守ります。 お金の表現 お金を動かしたり記録したりする前に、それを表現する必要があります。これらは、金銭的価値がどのようにモデル化され、保存され、計算され、変換されるかについての決定です。これらを間違えると、上のすべてのレイヤーがエラーを継承します。 精度の扱い お金の表現は、金融システムにおいて最も基本的な決定の一つです。これを行うには主に4つの方法があります。 浮動小数点。組み込みのfloatまたはdouble型。これは予測不能な精度損失を引き起こす可能性があり、ほとんど良い考えではありません。しかし、これは最も高速でメモリ効率が高く、追加のライブラリやデータ構造を必要としません。 任意精度。JavaのBigDecimalのような型は、計算の精度を正確に制御できます。コードは予測可能で、どこでどのように丸めが発生するかを決定できます。多くの操作が連鎖するFXや価格設定の計算などの中間作業に適しています。 最小単位精度。ほとんどの法定通貨では、接続された中央銀行システムで使用されるのと同じ固定精度を保持するだけで問題ありません。桁数はISO 4217で記述されています（常に2であると仮定しないでください、そうではありません！）。実際には、金額を最小単位の整数として保存することを意味します。€12.34は1234になります。仮想通貨も同じ整数最小単位のアイデア（BTCのサトシ、ETHのwei）を使用しますが、2つのひねりがあります。精度は資産ごとで、トークン自体（例：ERC-20のdecimals）によって定義され、しばしば18桁であり、結果として生じる桁数は64ビット整数をオーバーフローするため、任意幅の整数で保持する必要があります。 有理数。精度損失が許容されない場合。これは最も強力なアプローチですが、独自の注意点があります。第一に、他の選択肢よりも遅いです。第二に、精度を失うことなく他の形式に変換することはできません。第三に、通常はカスタムデータ型またはライブラリが必要です。 いずれかを選択することは、システムのクラスとその責任によります。浮動小数点を使用しないこと以外に経験則はありません。これらの表現は相互に排他的でもありません。金額をどのように保存し、どのように計算するかは別々の決定であり、システムはしばしばそれらを組み合わせます。例えば、整数ストレージとBigDecimalを中間計算に使用するなどです。金額がシリアル化される際にも同じ注意が必要です。生のJSON数値は、ほとんどのパーサーではIEEE-754 doubleであるため、金額を数値としてシリアル化すると、内部でどれだけ注意深く表現しても、浮動小数点問題がエッジで再導入されます。金額は文字列("12.34")として、または最小単位の整数として送信してください。 触れられた原則：データを失わない。間違った表現は、回復できない精度を静かに落とします。 丸め戦略 丸めは避けられません。それは明示的に行われるべきです。あらゆる除算、通貨換算、手数料、利息やレートの適用、または精度間の移動は丸めを必要とするかもしれません。それはビジネス上の決定です。異なる丸め戦略は異なる影響を与えます。時には保守的でなければならず（例：持っていないものを費やさない）、切り捨てる必要があります。時には統計的効果を考慮し、half-evenを使用します。端数を誰が得るかを決定することは、法的/税務上の影響を持つかもしれません。 できるだけ頻繁に丸めないでください。完全な精度を長く保持するほど、適切な文脈で適切な決定を下すための選択肢が増えます。丸めは通常、境界で行われるべきです。例えば、数値が永続化される前やユーザーに表示される前などです。 丸めは合計を壊します。数値が部分に分割され、丸めが適用されると、部分の合計が元の数値と等しくなくなる可能性があります。文脈によっては、これには明示的な処理が必要となる場合があります。例えば、明示的な丸め勘定などです。 触れられた原則：データを失わない。残差は追跡されなければならず、落とされてはなりません。データを作り出さない。丸めによって存在しなかったお金が作り出されてはなりません。 通貨の扱い お金は数値だけで表現することはできません。通貨とペアになっています。通貨を扱う際にはいくつかのニュアンスがあります。 金額と通貨を一緒にパックする。Money newtype（構造体、クラス、レコードなど）はエラーの可能性を最小限に抑えます。 異通貨間の算術演算を禁止する。システムは、異なる通貨の2つの金額を加算することを禁止すべきです。変換は厳密に管理されたレートで非常に明示的に行われるべきです。 管理された通貨セットを使用する。カスタム設定エントリ、JDKデータベース、専用サービスなど。任意の通貨コードを受け入れず、システムの境界で検証してください。コードは法定通貨のみを識別します。通貨コードは一意であり、法定通貨の識別子としてのみ使用可能です。仮想通貨の場合は、（ネットワーク、コントラクトアドレス）のような、より複雑なアプローチを使用する必要があります。 通貨はメタデータを持ちます。記号、精度、名前など。これらの詳細は通常、表示目的で必要ですが、ビジネスロジックではめったに必要ありません。ペッグされたものは基盤となるものではありません。ペッグされた、ブリッジされた、ラップされた仮想通貨は、基盤となるものと等価ではありません。 触れられた原則：信頼しない。境界で管理されたセットに対して通貨を検証します。データを作り出さない。異なる通貨/資産を互換性があるものとして扱うと、価値を創造してしまいます。 FXレート FX（Forex、外国為替市場）レートにより、通貨間で資金を変換できます。レートは常に方向性を持っています。EUR/USDレートは、逆のUSD/EURレートと同じではありません。取引所では、買いと売りは異なる価格（買値/売値スプレッド）での2つの異なる注文であるため、2つの方向は単純に反転しません。 レートの時間は重要です。技術的には任意の時点のレートを使用できますが、最も一般的に使用されるのは次のとおりです。 現在の時刻レート。現在の保有額や、今すぐ取引が行われたかのような取引の価値を計算するために使用されます。 価値日レート。価値の変化や税額を計算するために使用されます。 変換には2種類のレートが重要です。 取引レート。実際の変換が行われたレート。これを直接保存するのではなく、元の金額と結果の金額から導き出されます。 参照レート（仲値または中央銀行）。評価と等価性（保有額が今いくらであるか、または価値日時点での税金ベース）のために使用され、誰も実際に取引しない価格です。 標準的なレートはありません。レートは市場から来て、場所や計算方法によって異なります。標準に最も近いのは中央銀行レートであり、これは参照レートとしてのみ使用できます。そこでも、同じくらい有効な代替ソースが存在する可能性があります。 触れられた原則：データを失わない。金額（および、参照レートの場合はソースへの経路）を保持します。信頼しない。標準的なレートはないため、ソースはデータの一部であるべきです。 お金の記録：元帳 一度表現されたお金の動きは