الكلام ذا مهم لو أنت شغال على أنظمة فنتك (وليس أنظمة بنكية).

الكلام ذا مهم لو أنت شغال على أنظمة فنتك (وليس أنظمة بنكية).

لا تفترض إن كل العملاء بيتعاملوا بنفس العملة.

حتى لو التطبيق موجه بالكامل للسعودية وتتعامل فقط بالريال. فكر كيف بيتفاعل نظامك مستقبلاً لو جاء عميل حول بالدولار أو تستثمر في صندوق صيني أو تحتاج تتكامل مع خدمة دولية.

إذا كان الـ ledger عندك يسجل بس amount بدون أي معلومة عن العملة فأنت فتحت على نفسك باب مشاكل كبير.

بالنسبة لي أحب أشتغل دائمًا بهذا النموذج المرن داخل الـ Ledger: • sourceAmount + sourceCurrency: المبلغ والعملة الأصلية من العميل • convertedAmount + convertedCurrency: المبلغ بعد التحويل حسب حاجة الوظيفة (مثلاً استثمار خارجي) • baseAmount + baseCurrency: القيمة بالعملة المعتمدة للنظام (مثلاً الريال) حسب المنطقة. (ممكن مستقبلاً تحتاج تتوسع لدولة أخرى وتعتمد عملة الدولة العملة الافتراضية اللي النظام يتعامل معاها).

النموذج ذا يعطيني : تتبع دقيق (Traceability) مرونة مع عمليات تحويل متعددة (Multi-hop FX) جاهزية لأي توسع خارجي التزام واضح بالتدقيق والامتثال.

في نقطة حطها ببالك كل شيء في هندسة البرمجيات Trade-off.

من العيوب بهذا الأسلوب

تكرار البيانات عبء في عمليات الحفظ والتحديث Queries أبطأ

أنا دائما أقف بصف الاستدامة في البزنسس على حساب التكلفة التقنية.اللي يضحي بالتوسع مقابل كود نظيف بيدفع الثمن لاحقًا. أحاول أكون حريص إن النظام يكون جاهز للتوسع والامتثال حتى لو على حساب الأداء اللحظي.

#Fintech #LedgerDesign #EngineeringChoices #BusinessFirst