お客様のニーズに合わせたパーソナライズされたFinMV見積もりについては、お問い合わせください。
あなたの会社のテクニカルディレクターは、金融プラットフォームの立ち上げを計画するときに、プロジェクトアーキテクチャオプションを選択する必要があります。彼が利用できるアーキテクチャオプションと、どれを選択するのが良いですか？
新しい投資プラットフォームには、単一のチーム、単一のデプロイメント、単一のデータベースがあります。この段階での分散システムのコストは、そのすべてがオーバーヘッドとして表れます。関数呼び出しで十分な場面でのネットワーク呼び出し、トランザクションで十分な場面での結果整合性、そして誰も担当していない運用負荷です。
そのため、デフォルトの実装はモジュール型です。オンボーディング、オファー、投資、支払い、書類、サービス、レポーティングは、単一のデプロイ可能なシステムの中で明示的な境界の内側に存在します。これをモジュール型にしているのはフォルダ構造ではなく、各モジュールが契約を持ち、自分のデータを所有し、自分自身のテストでカバーされているという事実です。
モジュールは、具体的な根拠がある場合に独立したサービスになります。その根拠はビジネス上のものであり、流行によるものではありません。
境界と契約がすでに存在しているため、切り出しは書き直しではなく計画された作業になります。これこそがこの作り方の意義です。選択肢は開かれたままで、コストも低く抑えられます。
ユーザーをブロックすべきでない作業 — 決済照合、書類生成、プロバイダーからのコールバック、レポーティング — はキューを通じて実行されます。RabbitMQやKafkaのようなメッセージブローカーは、スループットや統合トポロジーがそれを正当化する場合に導入されるのであって、デフォルトではありません。PostgreSQLは引き続き記録の基盤であり、Redisは本当に低レイテンシのキャッシュや協調が必要な場所で使われます。
私たちはモノリスも販売しませんし、マイクロサービスも販売しません。どちらも、まだ誰も問うていない質問への答えです。また、プラットフォームを本格的に見せるために分散システムを構築することもありません。アーキテクチャの見せかけは運用コストが高く、引き継ぎも困難です。
アーキテクチャは、貴社の規模、規制上の義務、統合、そしてそれを運用するチームの規模から選ばれ、それらが変化したときに一緒に変化できるように設計されています。
