銀行のようなサブシステムを自分のショップに追加しようとしています。
私たちはすでに顧客を持っているので、それぞれに一種のアカウントが与えられ、何らかの取引が可能になります (アカウントに追加するか、アカウントから削除します)。
そのため、少なくともアカウントエンティティ、トランザクションエンティティ、および操作が全体的な残高を再計算する必要があります。
これを処理するには、データベースをどのように構成しますか?
モックできる標準的な銀行システムを使用する必要はありますか?
ところで、ここでは mysql を使用していますが、パフォーマンスを向上させるために nosql ソリューションも検討します。
高速化のためにNoSQLが必要になるとは思いません。多くの/まったく並列処理が必要になる可能性は低く、スキーマ指向ではない必要があるかどうかわからないからです。ただし、収益性など、何百万もの顧客と何億ものトランザクションを分析するための複雑なビジネス要件に取りかかる場合を除きます。それが大きくなった場合の最初の場所。
リレーショナル設計では、残高の再計算が必要な設計は避ける傾向があります。これは、残高修復プログラムなどが必要になるためです。適切なインデックス作成と十分に単純な設計により、トランザクション (正と負) で単純な SUM を実行できます。 ) バランスを取ります。トランザクションに関する適切で一貫した符号規則 (足し算するか引き算するかについてあいまいさがなく、常に値を足し合わせる) と適切な制約 (限られた数のトランザクションの種類で、すべての預金が正で、すべての引き出しが負であることを制約で指定できます) を使用します。 ) マイナス預金のような異常がないことをデータベースに保証させることができます。
なんらかの方法で残高をキャッシュしたい場合でも、トランザクション テーブルのトリガーで強化されたこのような単純なメカニズムを利用して、アカウント サマリー テーブルを更新することができます。
私は、これをデータベースの外の中間層に配置することはあまり好きではありません。基本的なアカウンティングは、データベース エンジン内で高速に処理できるように非常にシンプルである必要があります。これにより、クエリを実行するアプリケーションのすべてのユーザーまたは一部が、クライアント コード ロジックを関与させることなく同じ回答を得ることができます。そのため、データベースは、制約、トリガー、およびストアド プロシージャの組み合わせを使用して、参照整合性よりもわずかに高いレベルで整合性を保証します (ゼロ以外の残高を持つアカウントを閉じることは許可されない、残高がマイナスになることは許可されないなど)。必要に応じて複雑さの順序を増やします。すべてのビジネス ロジックについて話しているわけではありませんが、
実際の銀行業務 (つまり、COBOL アプリ) では、通常、データベース スキーマ (通常は非リレーショナルで非正規化 - これらの多くは SQL よりも前のものです) では、過去の残高の 12 か月のバケットのようなものが多く見られます。アカウントがロールオーバーします。これらのシステムが使用するデータベースの一部は、一種の階層構造になっています。すべてがコードで行われるため、ここでコードが非常に重要になります。繰り返しになりますが、それは一種の時代遅れであり、あらゆる種類の問題 (つまり、おそらく NatWest が経験していることとよく似ています) の影響を受けやすく、NoSQL は、このコードが王様であるという見方に逆戻りする傾向にあります。私は、これらのことを長い間扱った後に考える傾向があります-残高がキャッシュされたシステムを持つのは好きではありません。また、ポイントインタイムの説明責任が実際にないシステムは好きではありません-つまり
誰かが銀行のようなデータベース設計の「標準的な」パターンを持っていると確信していますが、何年にもわたっていくつかの会計のようなシステムを構築してきたにもかかわらず、私はそれらを認識していません.口座と取引はそれほど複雑ではありません.そのコンセプトにより、すべてが高度にカスタマイズされます。
たとえば、場合によっては、GAAP に基づくある種のスケジュールで契約の収益を認識し、時間の経過とともに支払われる契約を認識することがあります。銀行業務では、資金のコストなどのさまざまな金利を伴う多くの金利関連のものがあります。お金の出入りの会計の基本だけでビジネスのニーズを混ぜ始めると、すべてがユニークになります。
アプリに UI とデータベースの間に中間層があるかどうかはわかりません。その場合、トランザクションをマークして残高を再計算する場所を選択できます。このデータベースが 1 つのアプリケーションによって完全に所有されている場合は、計算を中間層に移動して、永続化のためにデータベースのみを使用できます。
Spring は、トランザクションを宣言するための優れたアノテーション ベースの方法を持つフレームワークです。これは POJO に基づいています。EJB の代替。これは、依存性注入、アスペクト指向プログラミング、優れたライブラリの 3 本足のスツールです。おそらく、アプリの構造化と実装の両方に役立つでしょう。
中間層があり、それがオブジェクト指向言語で書かれている場合は、Martin Fowler の「Analysis Patterns」を参照することをお勧めします。それは長い間存在してきましたが、金融システムに関する章は、それが最初に書かれたときと同じように今日でも優れています.