https://virgool.io/feed/@m_15490185 fa 2026-06-16 05:13:01 https://files.virgool.io/upload/users/1272227/avatar/tsg0ed.png?height=120&width=120 https://virgool.io/@m_15490185 https://virgool.io/@m_15490185/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%81%D9%86%DB%8C-%D9%88-%D8%B2%DB%8C%D8%B1%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7%DB%8C-%D8%B3%D8%A7%D9%85%D8%A7%D9%86%D9%87-%D8%A8%D8%A7%D9%86%DA%A9%D8%AF%D8%A7%D8%B1%DB%8C-%D9%85%D8%AA%D9%85%D8%B1%DA%A9%D8%B2-core-banking-system-ntcordxifple مقدمه: هسته مرکزی بانک مدرنسامانه بانکداری متمرکز (Core Banking System یا به اختصار CBS) قلب تپنده هر مؤسسه مالی است. این سامانه مسئولیت ثبت، پردازش، اعتبارسنجی و نگهداری تمامی تراکنش‌های بانکی را بر عهده دارد؛ از افتتاح حساب و واریز وجه گرفته تا پرداخت تسهیلات و تسویه‌های بین‌المللی، همگی در نهایت به CBS ختم می‌شوند. در معماری متمرکز سنتی، یک پایگاه داده مرکزی و یک هسته پردازشی واحد، وضعیت مالی مشتریان، مانده حساب‌ها و دفتر کل بانک را در لحظه به‌روز نگه می‌دارد. اما تحولات سال‌های اخیر — از ظهور بانکداری دیجیتال و تراکنش‌های آنی تا الزامات سخت‌گیرانه نظارتی و نیاز به در دسترس‌پذیری ۲۴/۷ — معماران را به بازاندیشی در ساختار این سیستم‌ها واداشته است.Core Banking Systemبررسی تطبیقی معماری‌های رایج در CBSمعماری یکپارچه (Monolithic)در این رویکرد قدیمی اما همچنان پرکاربرد، کل سامانه به صورت یک اپلیکیشن واحد با پایگاه داده مشترک پیاده‌سازی می‌شود. تمام زیرسیستم‌ها — مانند مدیریت حساب، پردازش وام، ماژول پرداخت و گزارش‌گیری — در یک فرایند واحد اجرا شده و از طریق فراخوانی مستقیم توابع با یکدیگر ارتباط برقرار می‌کنند. مزیت اصلی این معماری، سادگی در مدیریت تراکنش‌های اسیدی (ACID) و تضمین سازگاری قوی (Strong Consistency) داده‌هاست، چرا که تمام تغییرات درون یک محدوده تراکنشی واحد روی یک بانک اطلاعاتی رخ می‌دهد. با این حال، این رویکرد چالش‌های جدی برای بانک‌های امروزی ایجاد کرده است: هر تغییر جزئی در یک زیرسیستم، نیاز به تست و استقرار مجدد (Redeployment) کل سامانه دارد؛ مقیاس‌پذیری عمودی (افزایش توان سخت‌افزاری) به سرعت به سقف اقتصادی خود می‌رسد؛ و وجود یک باگ در بخش پرداخت می‌تواند کل عملیات سپرده‌گذاری را از کار بیندازد.معماری مبتنی بر میکروسرویس (Microservices)در مقابل، معماری میکروسرویس هر قابلیت بانکی را به عنوان یک سرویس مستقل و کوچک با پایگاه داده اختصاصی تعریف می‌کند. سرویس سپرده‌ها، سرویس وام، سرویس مشتری، سرویس پرداخت و... هر کدام به صورت جداگانه توسعه، استقرار و مقیاس‌دهی می‌شوند و از طریق APIهای سبک (معمولاً REST یا gRPC) یا با استفاده از پیام‌رسان‌های غیرهمزمان مانند Kafka با یکدیگر تعامل دارند. مزیت کلیدی برای بانک‌های بزرگ، قابلیت توسعه موازی توسط تیم‌های مجزا و مقیاس‌پذیری افقی (Horizontal Scaling) مستقل هر سرویس است. به عنوان مثال، در ساعات اوج تراکنش‌ها، تنها سرویس پرداخت نیاز به افزایش نمونه‌ها (Instances) دارد. چالش اصلی اما مدیریت تراکنش‌های توزیع‌شده و حفظ سازگاری داده‌ها در صورت خرابی یکی از سرویس‌هاست.معماری ابری-بومی (Cloud-Native)این رویکرد گامی فراتر از میکروسرویس برداشته و از مفاهیمی مانند کانتینرها (Docker)، ارکستراسیون (Kubernetes)، مش سرویس (Service Mesh مانند Istio) و تأمین خودکار زیرساخت (Infrastructure as Code) استفاده می‌کند. یک CBS ابری-بومی قادر است در پاسخ به نوسانات حجم تراکنش‌ها به طور خودکار نمونه‌های جدید ایجاد کند، در صورت خرابی یک نود بی‌درنگ آن را جایگزین سازد و به‌روزرسانی‌های پیوسته (Continuous Delivery) را بدون وقفه در ارائه سرویس انجام دهد. بانک‌هایی که از ابتدا روی این معماری سرمایه‌گذاری می‌کنند، مزیت رقابتی آکاری در سرعت ارائه سرویس‌های جدید و کاهش هزینه‌های عملیاتی به دست می‌آورند، اما پیچیدگی زیرساخت و نیاز به تغییر فرهنگ سازمانی از موانع اصلی پذیرش آن است.زیرسیستم مدیریت حساب و دفتر کل (General Ledger)دفتر کل توزیع‌شده در یک CBS مدرن، دیگر یک جدول ساده رابطه‌ای نیست. این زیرسیستم باید ساختار حساب‌ها را به صورت سلسله‌مراتبی (حساب‌های کل، معین و تفصیلی) به همراه ویژگی‌هایی مانند نوع حساب (سپرده قرض‌الحسنه، جاری، پس‌انداز، بلندمدت)، مالکیت (حقیقی، حقوقی، مشترک) و محدودیت‌های عملیاتی (حداکثر برداشت روزانه، نرخ سود علی‌الحساب) مدیریت کند. پیاده‌سازی دفتر کل توزیع‌شده به معنای آن است که اجزای مختلف دفتر ممکن است روی شاردهای (Shard) متفاوتی از پایگاه داده قرار گیرند یا حتی در دیتاسنترهای جغرافیایی جداگانه توزیع شده باشند.ثبت تراکنش‌های دوطرفه (Double-Entry) همچنان سنگ بنای صحت حسابداری بانکی است. هر رویداد مالی باید حداقل دو ورودی داشته باشد: یک بدهکاری در یک حساب و یک بستانکاری معادل در حساب دیگر.برای نمونه، هنگام واریز نقدی به حساب جاری مشتری، حساب «صندوق» بانک بستانکار (کاهش) و حساب جاری مشتری بدهکار (افزایش) می‌شود. در یک سیستم توزیع‌شده، اجرای این قانون ساده اما حیاتی به معماری‌های پیچیده‌تری نیاز دارد: هر سرویس (مثلاً سرویس سپرده و سرویس نقدینگی) باید قبل از نهایی‌سازی تراکنش، از سازگاری دفتر کل اطمینان حاصل کند. برای حسابرسی مالی نیز باید تمامی تغییرات به صورت دفتر روزنامه (Journal) با قابلیت بازگشت‌ناپذیری (Immutable) ثبت شوند — موضوعی که استفاده از بلاکچین یا دفتر کل نامتمرکز را در برخی پیاده‌سازی‌های پیشرو توجیه می‌کند.هسته پردازش تراکنش و مدیریت تراکنش‌های توزیع‌شدهدر یک CBS یکپارچه، پردازش یک تراکنش ساده مانند انتقال وجه بین دو حساب داخلی، درون یک تراکنش پایگاه داده اسیدی (ACID) انجام می‌شود. اما در معماری میکروسرویس، این عملیات ساده به دو سرویس مجزا (سرویس حساب مبدأ و سرویس حساب مقصد) و احتمالاً یک سرویس دفتر کل مستقل تقسیم می‌شود. در اینجا دو الگوی اصلی برای حفظ سازگاری وجود دارد:پروتکل تعهد دوفازی (Two-Phase Commit - 2PC): که با نام آماده‌سازی و تعهد (Prepare & Commit) نیز شناخته می‌شود. در این الگو یک هماهنگ‌کننده (Coordinator) از همه سرویس‌های درگیر می‌پرسد: «آیا می‌توانید این تغییر را انجام دهید؟» اگر همه پاسخ مثبت بدهند، هماهنگ‌کننده فرمان نهایی‌سازی (Commit) را صادر می‌کند؛ در غیر این صورت همه را به حالت پیشین بازمی‌گرداند (Rollback). مزیت 2PC حفظ دقیق سازگاری قوی است، اما هزینه سنگین قفل‌گذاری طولانی‌مدت روی منابع و کاهش شدید در دسترس‌پذیری در صورت خرابی هماهنگ‌کننده، آن را برای سامانه‌هایی با نیازمندی پاسخ‌دهی زیر ثانیه نامناسب ساخته است.الگوی ساگا (Saga Pattern): در مقابل، این الگو تراکنش را به یک توالی از تراکنش‌های محلی (Local Transactions) تجزیه می‌کند که هر کدام توسط یک سرویس انجام شده و رویداد خود را منتشر می‌کند. اگر مرحله‌ای با شکست مواجه شود، ساگا تراکنش‌های جبرانی (Compensating Transactions) را به ترتیب معکوس اجرا می‌کند. برای مثال در انتقال وجه، ابتدا سرویس مبدأ مانده را کم می‌کند (مرحله ۱) و رویداد «وجه کسر شد» منتشر می‌کند. سرویس مقصد با شنیدن این رویداد، مانده را زیاد می‌کند (مرحله ۲). اگر مرحله ۲ شکست بخورد، سرویس مبدأ رویداد جبرانی «برگرداندن وجه کسرشده» را اجرا می‌کند.الگوی Saga سازگاری نهایی (Eventual Consistency) را تضمین می‌کند — یعنی پس از مدت کوتاهی سیستم به حالت درست خود می‌رسد — و هیچ قفل بلندمدتی ایجاد نمی‌کند، اما در لحظه کوتاهی پس از خطا، ممکن است داده‌ها در دو سرویس ناهماهنگ باشند.انتخاب بین 2PC و Saga مصداق مستقیم قضیه CAP است: در حضور پارتیشن شبکه (Partition)، آیا سازگاری (Consistency) را قربانی می‌کنید یا در دسترس‌پذیری (Availability) را؟ بانکداری متمرکز سنتی همواره سازگاری را ترجیح داده، اما بانکداری مدرن در بسیاری از موارد (مثل نمایش موقت مانده اشتباه در کنار پرداخت موفق) سازگاری نهایی را می‌پذیرد تا در دسترس‌پذیری ۲۴/۷ حفظ شود.ماژول‌های اصلی بانکیزیرسیستم سپرده‌ها (Deposits): این ماژول مسئول مدیریت انواع حساب‌های سپرده (جاری، پس‌انداز، کوتاه‌مدت، بلندمدت) و محاسبه خودکار سود بر اساس نرخ‌های شناور یا ثابت است. ویژگی‌های کلیدی شامل مسدودی وجوه (Block/Unblock)، سقف برداشت، صدور دسته‌چک الکترونیک و تولید گردش‌های روزانه می‌شود. معماری این ماژول باید از ثبت تراکنش‌های با حجم بسیار بالا (میلیون‌ها در ساعت) در ساعات اوج پشتیبانی کند.تسهیلات و وام‌ها (Lending): قلب درآمدزایی بانک. این زیرسیستم چرخه کامل اعطای تسهیلات — از درخواست و اعتبارسنجی (با اتصال به سامانه‌های اعتباری مانند سامانه نمره‌دهی اعتباری بانک مرکزی)، تصویب، قرارداد، پرداخت اصل تسهیلات، محاسبه اقساط (با روش‌های کاهش مانده یا سرمایه ثابت)، شناسایی اقساط معوق، تا مدیریت وصول — را پوشش می‌دهد. در معماری مدرن، موتور محاسبه سود و جریمه به عنوان یک سرویس مستقل با قابلیت تنظیم پویای نرخ‌ها بر اساس تأخیر پرداخت طراحی می‌شود.مدیریت مشتریان بانکی (Banking CRM): فراتر از یک CRM معمولی، این ماژول باید نمای ۳۶۰ درجه از مشتری شامل تمام حساب‌ها، تسهیلات، کارت‌ها، تعهدات، امضاءهای مجاز و مدارک احراز هویت (KYC) را در خود داشته باشد. همچنین مدیریت نقش‌ها (مدیر، کارشناس، ممیز)، سطح دسترسی و تاریخچه تعاملات با شعبه و اپلیکیشن موبایل از وظایف آن است. یکپارچگی با سیستم مبارزه با پولشویی (AML) برای اسکن تراکنش‌های پرخطر الزامی است.پردازش پرداخت‌ها (Payments): این ماژول دروازه ارتباطی بانک با شبکه‌های پرداخت (ساتنا، پایا، شتاب، سوئیفت) و درگاه‌های PSP است. قابلیت‌های کلیدی عبارتند از: مسیریابی هوشمند تراکنش بر اساس هزینه، زمان و در دسترس بودن مقصد؛ رعایت استانداردهای ISO 20022 برای پیام‌های مالی؛ مدیریت بچ (Batch) برای پرداخت‌های انبوه حقوق و غیره؛ و پیاده‌سازی مکانیسم‌های امنیتی مانند CVV2 پویا و توکن‌سازی (Tokenization) کارت.لایه دسترسی به داده و مدیریت پایگاه داده با در دسترس‌پذیری بالامعماری داده در CBS مدرن دو پیکربندی اصلی دارد:Active-Passive: در این حالت تنها یک نود پایگاه داده فعال است و نود دیگر به صورت آماده به کار (Standby)، تراکنش‌ها را به صورت همگام (Synchronous) یا غیرهمگام (Asynchronous) دریافت می‌کند. در حالت همگام، تراکنش تنها زمانی متعهد (Commit) می‌شود که روی هر دو نود نوشته شود؛ این کار حداکثر سازگاری را تضمین می‌کند اما تأخیر (Latency) را افزایش می‌دهد. در حالت غیرهمگام، نود فعال بدون انتظار برای نود آماده‌به‌کار، تراکنش را نهایی می‌کند و در صورت خرابی ناگهانی، احتمال از دست رفتن آخرین تراکنش‌ها (RPO بالاتر) وجود دارد.Active-Active: این پیکربندی هر دو نود را همزمان فعال نگه می‌دارد و درخواست‌ها را بین آن‌ها توزیع می‌کند. این رویکرد حداکثر در دسترس‌پذیری (99.999% یا پنج‌ناین) و مقیاس‌پذیری خواندن را فراهم می‌آورد، اما حل تعارض نوشتن همزمان روی یک رکورد در دو نود بسیار چالش‌برانگیز است. راهکارهای رایج شامل استفاده از شاردینگ مبتنی بر کلید (مثلاً توزیع مشتریان بر اساس شماره ملی) به طوری که هر مشتری همیشه به یک نود خاص نگاشت شود، یا استفاده از پایگاه‌های داده NoSQL با مدل سازگاری نهایی مانند Cassandra است.معیارهای RTO (Recovery Time Objective) و RPO (Recovery Point Objective) در بانک‌های بزرگ معمولاً به ترتیب کمتر از ۱۵ دقیقه و کمتر از ۱ ثانیه تعریف می‌شوند.دستیابی به این اعداد مستلزم ترکیبی از همگام‌سازی همزمان (برای RPO پایین) و زیرساخت خودکار Failover (برای RTO پایین) است. بسیاری از بانک‌ها از راهکارهای مبتنی بر کلاستر با توافق جمعی (Consensus algorithms مانند Raft یا Paxos) استفاده می‌کنند که بدون نیاز به یک نود هماهنگ‌کننده مرکزی، بین چندین نسخه از داده توافق ایجاد می‌کنند.امنیت، تاب‌آوری (Resiliency) و بازیابی فاجعه (Disaster Recovery)در صنعت بانکداری، امنیت تنها یک لایه نیست، بلکه در تمام لایه‌های معماری نفوذ کرده است. الزامات نظارتی مانند استاندارد PCI-DSS برای پردازش اطلاعات کارت‌های اعتباری، دستورالعمل‌های بانک مرکزی برای نگهداری حداقل ۷ سال از تراکنش‌ها، و الزام به رمزنگاری داده‌ها در حالت ذخیره‌سازی (Encryption at Rest) و در حال انتقال (Encryption in Transit) از حداقل‌های پذیرش هستند.استراتژی تاب‌آوری (Resiliency) شامل «طراحی برای شکست» (Design for Failure) است؛ یعنی هر مؤلفه باید در برابر خرابی مؤلفه‌های وابسته مقاوم باشد. الگوهایی مانند:قطع مدار (Circuit Breaker): که پس از تعداد مشخصی خطا از یک سرویس، درخواست‌ها را بدون اجرای واقعی با خطا برمی‌گرداند.الگوی Retry با Backoff نمایی: تکرار درخواست با فاصله‌های فزاینده.الگوی Bulkhead: تقسیم منابع به بخش‌های ایزوله که تضمین می‌کند ازدحام در سرویس پرداخت، سرویس سپرده را مختل نکند.بازیابی فاجعه (DR) فراتر از خرابی‌های سخت‌افزاری ساده است. یک سناریوی واقعی شامل آتش‌سوزی در دیتاسنتر، قطع برق منطقه‌ای یا حتی حمله سایبری گسترده است. استراتژی‌های Failover باید حداقل سه سطح داشته باشند: Failover درون یک رک (به یک سرور جایگزین)، Failover درون دیتاسنتر (به یک کلاستر مجزا)، و Failover برون‌شهری (به دیتاسنتر دوم در شهر یا استان دیگر). هر سطح به نوبه خود هزینه و پیچیدگی را افزایش می‌دهد، اما دستیابی به هدف 99.999% در دسترس‌پذیری (کمتر از ۵.۲۶ دقیقه خرابی در سال) بدون DR برون‌شهری غیرممکن است. آزمایش‌های منظم بازیابی (Disaster Recovery Drills) — حداقل سالی دو بار — بخش جدایی‌ناپذیر از فرایندهای عملیاتی بانک است.چالش‌های مهاجرت سیستم‌های سنتی (Legacy Migration) به معماری مدرنمهاجرت از یک CBS یکپارچه و اغلب مبتنی بر فناوری‌های قدیمی مانند COBOL و پایگاه داده‌های غیررابطه‌ای اختصاصی، یکی از پرریسک‌ترین پروژه‌های فناوری اطلاعات در بانک‌هاست.الگوی خفه‌کننده (Strangler Pattern): این الگو که توسط مارتین فاولر معرفی شده، رویکردی تدریجی ارائه می‌دهد؛ به جای بازنویسی یک‌باره کل سیستم، قابلیت‌های جدید را به صورت میکروسرویس‌های مجزا پیاده‌سازی کنید و مسیریاب (Router / API Gateway) را طوری تنظیم کنید که درخواست‌های مربوط به آن قابلیت، ابتدا به سرویس جدید هدایت شوند. سپس به تدریج قابلیت‌های قدیمی را از سیستم یکپارچه خارج کرده و با سرویس‌های جدید جایگزین کنید، تا جایی که سیستم قدیمی کاملاً جای خود را به سیستم جدید بدهد.مهاجرت فازی (Phased Migration): این رویکرد عملی‌تر است؛ ابتدا زیرسیستم‌های کم‌ریسک مانند مدیریت اطلاع‌رسانی (SMS و ایمیل مشتریان) را منتقل کنید، سپس به سراغ ماژول‌های اصلی مانند سپرده‌ها بروید و در نهایت وام و پرداخت را مهاجرت دهید. در تمام این مدت، هم سیستم قدیمی و هم سیستم جدید به صورت همزمان اجرا می‌شوند و یک لایه همگام‌سازی داده (Data Sync Layer) اطمینان می‌دهد که تغییرات هر دو سیستم با یکدیگر سازگار بمانند.مدیریت ریسک در حین گذار مستلزم چند اقدام حیاتی است: اجرای موازی (Parallel Run) به مدت حداقل سه ماه که در آن هر تراکنش هم روی سیستم قدیم و هم روی سیستم جدید اجرا شده و خروجی‌ها مقایسه می‌گردند؛ طراحی یک نقشه بازگشت (Rollback Plan) دقیق با پنجره زمانی حداکثر یک‌ساعته؛ و آموزش گسترده کارکنان شعب و مرکز عملیات قبل از قطع کامل سیستم قدیمی.تجربه نشان می‌دهد که حتی با بهترین برنامه‌ریزی، ناهنجاری‌های داده‌ای پیش‌بینی‌نشده — مانند کدهای شبای نامعتبر، تاریخ‌های بازه‌ای در سیستم قدیم که با فرمت نادرست ذخیره شده‌اند، یا قوانین سوددهی پیچیده که مستند نیستند — در حین مهاجرت ظاهر می‌شوند. داشتن یک تیم واکنش سریع (SWAT Team) با دسترسی مستقیم به کد قدیم و جدید برای حل این موارد، ضرورتی انکارناپذیر است.#CoreBankingSystem #CBS #بانکداری_متمرکز #هسته_مرکزی_بانک #MonolithicArchitecture #معماری_یکپارچه #Microservices #میکروسرویس #CloudNative #ابری_بومی #GeneralLedger #دفتر_کل #DoubleEntry #حسابداری_دوطرفه #TransactionProcessing #پردازش_تراکنش #DistributedTransaction #تراکنش_توزیع‌شده #TwoPhaseCommit #2PC #SagaPattern #سازگاری_نهایی #EventualConsistency #CAPTheorem #Deposits #سپرده‌ها #Lending #تسهیلات_وام #BankingCRM #مدیریت_مشتریان #PaymentProcessing #پردازش_پرداخت #ActivePassive #ActiveActive #HighAvailability #دسترس‌پذیری_بالا #RTO #RPO #DisasterRecovery #بازیابی_فاجعه #Resiliency #تاب‌آوری #CircuitBreaker #قطع_مدار #BankingSecurity #امنیت_بانکی #PCIDSS #Encryption #رمزنگاری #LegacyMigration #مهاجرت_سیستم_سنتی #StranglerPattern #الگوی_خفه‌کننده #PhasedMigration #مهاجرت_فازی #BankingModernization #تحول_بانکداری #DigitalBanking #بانکداری_دیجیتال #OpenBanking #بانکداری_باز #CoreBankingTransformation #تحول_هسته_بانکی #BankingArchitecture #معماری_بانکی #FinancialServices #خدمات_مالی #FinTech #فینتک رحیم لطفی رحیم لطفی Thu, 11 Jun 2026 11:15:24 +0330 https://virgool.io/@m_15490185/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%81%D9%86%DB%8C-%DA%A9%D8%A7%D8%B1%DA%AF%D8%B2%D8%A7%D8%B1%DB%8C-%D8%A8%D9%88%D8%B1%D8%B3-%D8%A7%D8%B2-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-%D8%AA%D8%A7-%D9%85%D9%88%D8%AA%D9%88%D8%B1-%D8%AA%D8%B7%D8%A8%DB%8C%D9%82-%D8%B3%D9%81%D8%A7%D8%B1%D8%B4%D8%A7%D8%AA-zpb2c5q5ysjo در قلب بازار سرمایه، کارگزاری بورس به‌عنوان واسطی حیاتی میان سرمایه‌گذاران و نهادهای تسویه‌کننده (مانند بورس و شرکت سپرده‌گذاری مرکزی) ایفای نقش می‌کند. یک کارگزاری مدرن، فراتر از یک پلتفرم ساده برای خرید و فروش سهام، سیستمی پیچیده از زیرسیستم‌های هماهنگ است که باید در لحظه، داده‌ها را پردازش، سفارشات را مسیردهی و ریسک را مدیریت کند. در این مقاله، ساختار فنی یک کارگزاری تمام‌عیار را لایه‌به‌لایه تشریح می‌کنیم؛ از درگاه احراز هویت کاربر تا هسته معاملاتی و تسویه ناهمگام.معماری کارگزاری۱. زیرسیستم مدیریت کاربران، احراز هویت (KYC) و کنترل دسترسی (RBAC)پیش از هر معامله، هویت مشتری باید با بالاترین استانداردهای قانونی تأیید شود. زیرسیستم KYC (Know Your Customer) وظیفه گردآوری مدارک شناسایی، احراز نشانی و تطابق با لیست‌های نظارتی را بر عهده دارد. معمولاً این فرآیند با دریافت تصاویر کارت ملی و سلفی، تطبیق چهره (Face Matching) و استعلام از سامانه‌های مرجع (مانند سامانه سجام) انجام می‌شود. پس از تأیید، نقش (Role) کاربر در سیستم تعریف می‌گردد: معامله‌گر خرد، معامله‌گر نهادی، یا کارگزار داخلی.مدیریت دسترسی‌ها بر اساس مدل RBAC (Role-Based Access Control) پیاده‌سازی می‌شود. هر نقش دارای مجموعه‌ای از مجوزها (Permissions) نظیر «مشاهده سفارش»، «ثبت سفارش»، «تغییر حد ریسک» و «دسترسی به گزارشات مالی» است. توکن‌های احراز هویت معمولاً به شکل JWT با زمان انقضای کوتاه (مثلاً ۱۵ دقیقه) و قابلیت چرخش خودکار طراحی می‌شوند. همچنین، ذخیره رمزعبور با الگوریتم‌هایی نظیر bcrypt و اعمال قوانین سخت‌گیرانه (پیچیدگی و تاریخ انقضا) الزامی است. برای دسترسی‌های حساس (مانند تغییر رمز کیف پول یا برداشت وجه)، لایه دوم احراز هویت (OTP یا Google Authenticator) فعال می‌شود.۲. هسته معاملاتی و سیستم مدیریت سفارشات (OMS)سیستم مدیریت سفارشات (OMS) قلب تپنده کارگزاری است. سفارشات خرید و فروش از سمت کاربر (از طریق وب، اپلیکیشن موبایل یا API) وارد OMS می‌شوند. هر سفارش حاوی اطلاعاتی نظیر نماد، حجم، قیمت، جهت (خرید/فروش)، نوع سفارش (محدود، بازار، شرطی) و شناسه کاربر است. برخلاف تصور رایج، کارگزاری معمولاً خود موتور تطبیق سفارشات (Matching Engine) را اجرا نمی‌کند؛ این وظیفه به عهده هسته مرکزی بورس است. نقش کارگزاری در اینجا، اعتبارسنجی پیش از معامله، تعیین مسیر سفارش و ارسال بلادرنگ آن به درگاه بورس (معمولاً از طریق پروتکل FIX یا APIهای اختصاصی) است.OMS باید قادر باشد نرخ ارسال سفارش (Order Rate) بالایی را تحمل کند (مثلاً چند هزار سفارش در ثانیه). به همین دلیل، سفارشات در صف‌های داخلی (با استفاده از Redis یا Kafka) قرار گرفته و سپس به صورت گروهی (Batching) یا انفرادی به بورس ارسال می‌شوند. پس از ارسال، OMS منتظر دریافت شناسه سفارش (Order ID) و وضعیت تأیید اولیه از بورس می‌ماند. در صورت رد شدن سفارش به دلیل مشکلاتی مانند کمبود اعتبار یا محدودیت حجمی، خطای مربوطه بلافاصله به کاربر بازگردانده می‌شود.۳. زیرسیستم مالی، حسابداری و مدیریت کیف پول (Wallet)هر کاربر در کارگزاری دارای یک کیف پول (Wallet) است که موجودی نقدی وی را نشان می‌دهد؛ دارایی‌های سهام او نیز در سامانه داخلی کارگزاری (بر اساس استعلام از شرکت سپرده‌گذاری مرکزی) نگهداری می‌شود. زیرسیستم مالی باید دو طرف معامله را به صورت آنی مدیریت کند:الف) کاهش یا بلوکه کردن موجودی نقد هنگام ثبت سفارش خرید.ب) بلوکه کردن سهام در سبد دارایی هنگام ثبت سفارش فروش.چالش اصلی در اینجا تسویه حساب آنی نیست، بلکه تسویه در بازه استاندارد بازار (مثلاً T+2) است. با این حال، کارگزاری‌های مدرن برای ارائه تجربه کاربری بهتر، موجودی قابل معامله (Available Balance) را به صورت «شبه‌آنی» به‌روزرسانی می‌کنند. به این صورت که پس از اجرای معامله (دریافت گزارش اجرا از بورس)، سیستم مالی بلافاصله سهام فروخته‌شده را از پرتفوی کاربر خارج و معادل ریالی آن را به موجودی نقد (با اعمال فرآیند تسویه داخلی) اضافه می‌کند؛ اما تا زمان انجام تسویه نهایی قانونی، کاربر مجاز به برداشت فیزیکی آن مبلغ از حساب نیست.مدیریت کارمزدها نیز لایه دیگری از پیچیدگی است. کارمزد معاملات (شامل سهم کارگزاری، مالیات و کارمزد سازمان بورس) باید طبق جداول تعرفه‌ای پویا محاسبه و از کیف پول کاربر کسر شود. پلتفرم‌های پیشرفته، موتور محاسبه کارمزد را به صورت یک میکروسرویس جداگانه و با قابلیت تنظیم بر اساس حجم معاملات ماهانه، سطح کاربر (VIP) و تخفیف‌های دوره‌ای طراحی می‌کنند.۴. سیستم مدیریت ریسک پیش از معامله (Pre-Trade Risk)یکی از حیاتی‌ترین لایه‌های معماری کارگزاری، موتور کنترل ریسک پیش از معامله است. این زیرسیستم قبل از ارسال هر سفارش به بورس، چندین قاعده سخت‌گیرانه را ارزیابی می‌کند:موجودی نقد کافی برای سفارش خرید (با احتساب کارمزدها).موجودی سهام کافی برای سفارش فروش (بر اساس پرتفوی واقعی کاربر).حداکثر حجم سفارش برای یک نماد خاص (جهت کنترل نوسان‌گیری ناشی از خطا).قوانین حد ضرر روزانه (مثلاً مسدودسازی معاملات جدید در صورت عبور ضرر روزانه کاربر از یک درصد مشخص).کنترل سقف سرمایه‌گذاری (جلوگیری از انحصار یا خرید بیش از حد مجاز یک سهم).این قوانین باید با تأخیری کمتر از ۵ میلی‌ثانیه پردازش شوند. برای این منظور، وضعیت لحظه‌ای موجودی و پرتفوی هر کاربر در یک حافظه موقت پرسرعت (مانند Redis Cache) نگهداری می‌شود. پس از تأیید ریسک، سفارش به مرحله بعد (OMS) راه پیدا می‌کند و در صورت رد شدن، دلیل دقیق آن بلافاصله به کاربر اعلام می‌شود. برای کاربران اعتباری، این زیرسیستم پیچیده‌تر شده و شامل محاسبه نسبت وثیقه (Collateral Ratio) و فراخوانی مارجین (Margin Call) می‌گردد.۵. توزیع داده‌های لحظه‌ای بازار (Market Data Feed)کاربران برای تصمیم‌گیری نیازمند دریافت قیمت‌های لحظه‌ای، عمق بازار (Order Book) و حجم معاملات هستند. کارگزاری خود تولیدکننده داده‌های بازار نیست، بلکه از طریق اتصال مستقیم (Feed) به بورس، داده‌ها را دریافت کرده و پس از نرمال‌سازی، بین کاربران خود توزیع می‌کند.پروتکل‌های استاندارد برای انتقال داده‌های لایو شامل WebSocket (برای اتصال پایدار و دو‌طرفه در مرورگر و اپلیکیشن) و gRPC Stream (برای ارتباط میان‌سروری با کارایی بالا) است. معماری توزیع داده اغلب به صورت Publisher-Subscriber (مانند Kafka یا Redis Pub/Sub) طراحی می‌شود؛ به این صورت که هر نماد یک Topic اختصاصی دارد. سرور کارگزاری دیتای دریافتی از بورس را روی Topic متناظر منتشر می‌کند و گیت‌وی‌های وب‌ساکت (WebSocket Gateways) که کاربران به آن‌ها متصل هستند، داده‌ها را به صورت فشرده‌سازی شده (مثلاً با فرمت Protobuf یا MessagePack) برای کلاینت‌ها ارسال می‌کنند.چالش اصلی این بخش، مقیاس‌پذیری برای هندل کردن هزاران اتصال همزمان و نرخ بالای به‌روزرسانی داده‌ها است. استفاده از بافرها و مکانیزم‌های بازیابی پیام‌های از دست رفته (مانند ذخیره آخرین اسنپ‌شات بازار در Redis) در این لایه ضروری است.۶. نیازمندی‌های غیرعملیاتی معماری: مقیاس‌پذیری، صف‌ها و کشیک کارگزاری مدرن تحت هیچ شرایطی نمی‌تواند به معماری یکپارچه (Monolithic) بسنده کند. سه نیازمندی کلیدی زیر، زیرساخت این سیستم را شکل می‌دهند:مقیاس‌پذیری افقی (Horizontal Scalability): تمام سرویس‌ها (OMS، مدیریت ریسک، API Gateway و توزیع داده) باید بدون تغییر در کد و صرفاً با افزودن لایه‌های سخت‌افزاری جدید (Instances)، توان عملیاتی خود را افزایش دهند. این امر مستلزم بی‌حالت (Stateless) بودن لایه پردازش است؛ به طوری که وضعیت کاربران در دیتابیس یا سیستم کش مجزا نگهداری شود.مدیریت صف‌ها (Message Queues): برای عملیات ناهمگام (Asynchronous) مانند فرآیند نهایی تسویه، ارسال نوتیفیکیشن‌ها، تولید گزارش‌های پایان روز و به‌روزرسانی تاریخچه معاملات، از صف‌های پیام مانند RabbitMQ یا Apache Kafka استفاده می‌شود. به عنوان مثال، به محض دریافت گزارش اجرای معامله از بورس، یک پیام به صف «تسویه» فرستاده می‌شود تا سرویس‌های پشتیبان بدون معطل کردن ترافیک اصلی شبکه، موجودی کاربر را به‌روزرسانی کنند. Kafka به دلیل نگهداری لاگ‌ها و قابلیت پخش مجدد (Replay)، برای بازسازی وضعیت حسابداری در یک نقطه زمانی خاص بسیار مناسب است.سیستم‌های Caching (مانند Redis): خواندن مداوم وضعیت موجودی و پرتفوی از پایگاه داده‌های رابطه‌ای (مثل PostgreSQL) به دلیل تاخیر بالا غیرممکن است. به همین دلیل، از Redis به عنوان یک کش درون‌حافظه‌ای (In-Memory) توزیع‌شده استفاده می‌شود. ساختار داده مناسب در اینجا، Hash برای نگهداری موجودی هر کاربر (کلید: wallet:userId و فیلد: cashBalance) و Sorted Set برای پیگیری سفارش‌های فعال بر اساس زمان است. همچنین، اعمال مکانیزم‌های پایدارسازی داده (Persistence) در Redis در کنار قابلیت Replication، برای جلوگیری از پریدن دیتا در صورت خاموش شدن ناگهانی سرور الزامی است.در نهایت، یک دیتابیس تراکنشی قدرتمند (SQL) تمام رویدادهای مالی و سوابق را به صورت دائمی ذخیره می‌کند تا در صورت بروز هرگونه کرش در سیستم، امکان بازسازی کامل وضعیت کش از روی لاگ رویدادها (Event Sourcing) وجود داشته باشد.طراحی یک کارگزاری مدرن، تلفیقی از دانش مالی، معماری سیستم‌های بلادرنگ (Real-time) و مهندسی زیرساخت است. هر زیرسیستم توضیح‌داده‌شده — از KYC و RBAC گرفته تا موتور ریسک پیش از معامله، توزیع داده لایو با WebSocket و معماری مبتنی بر صف و کش — باید با بالاترین استانداردهای پایداری (99.99%)، ثبات داده و امنیت سایبری ساخته شود. توجه به این جزئیات فنی نه تنها تجربه کاربری روانی را رقم می‌زند، بلکه ثبات پلتفرم را در روزهای پرترافیک بازار تضمین می‌کند.#معماری_کارگزاری_مدرن #هسته_معاملاتی #سیستم_مدیریت_سفارشات #OMS #احراز_هویت #KYC #کنترل_دسترسی #RBAC #مدیریت_ریسک_پیش_از_معامله #کیف_پول #زیرسیستم_مالی #تسویه_ناهمگام #T+2 #توزیع_داده_لحظه_ای #WebSocket #gRPC #صف_پیام #Kafka #Redis #کش_درون_حافظه #مقیاس_پذیری_افقی #امنیت #bcrypt #JWT #کارمزد_پویا #مارجین #وثیقه #معماری_بی_حالت #EventSourcing #پروتکل_FIX #عمق_بازار #OTP #سبد_دارایی #سامانه_سجام #پایداری_99.99 #مهندسی_بلادرنگ #BrokerageArchitecture #OrderManagementSystem #PreTradeRisk #IdentityVerification #RealTimeMarketData #MessageQueues #HorizontalScalability #WalletAccounting #SettlementCycle #CollateralMargin #DynamicCommission #FIXProtocol #EventSourcing #HighAvailability #LowLatency #APIGateway #Microservices #OrderRouting رحیم لطفی رحیم لطفی Thu, 04 Jun 2026 01:42:53 +0330 https://virgool.io/@m_15490185/%D9%87%D8%B3%D8%AA%D9%87-%D9%85%D8%B9%D8%A7%D9%85%D9%84%D8%A7%D8%AAtrading-core-%D9%85%D8%BA%D8%B2-%D9%85%D8%AA%D9%81%DA%A9%D8%B1-%D8%A8%D8%A7%D8%B2%D8%A7%D8%B1-%D8%B3%D9%87%D8%A7%D9%85-%D9%88-%D8%A7%D8%B1%D8%B2-%D8%AF%DB%8C%D8%AC%DB%8C%D8%AA%D8%A7%D9%84-mnwkrpdbj7ml مقدمه: یک رستوران شلوغ را تصور کن…فرض کن در یک رستوران بسیار شلوغ نشسته‌ای. چندین پیشخدمت در حال رفت‌وآمد بین آشپزخانه و میزها هستند. مشتری‌ها (معامله‌گران) سفارش می‌دهند و پیشخدمت‌ها (کارگزاران یا گیت‌وی‌ها) این سفارش‌ها را به آشپزخانه می‌برند. اما در قلب آشپزخانه، شخصی به نام سرآشپز اجرا (هسته معاملات) ایستاده است. او دقیقاً می‌داند چه موادی موجود است، چه سفارش‌هایی در صف قرار دارند و کدام غذا باید زودتر آماده شود. اگر این سرآشپز نباشد، هیچ غذایی به دست مشتری نمی‌رسد.در دنیای بازارهای مالی هم دقیقاً همین اتفاق می‌افتد. چه در بورس اوراق بهادار تهران باشید و چه در صرافی ارز دیجیتالی مثل بایننس، یک «سرآشپز اجرا» به نام هسته معاملات (Matching Engine) وجود دارد. وظیفه او دریافت سفارش‌های خرید و فروش، تطبیق آن‌ها با یکدیگر و نهایی کردن معامله است. در این مقاله می‌خواهیم با همین زبان ساده بررسی کنیم که هسته معاملات چیست، از چه اجزایی تشکیل شده و چرا قلب تپنده بورس و کریپتو محسوب می‌شود.Trading Coreبخش اول: هسته معاملات دقیقاً چیست؟هسته معاملات یک نرم‌افزار فوق‌العاده سریع (و در سطح کلان، ترکیبی از سخت‌افزار و نرم‌افزار) است که سه وظیفه اصلی دارد:۱. دریافت مداوم سفارش‌های خرید و فروش.۲. جفت کردن (تطبیق) این سفارش‌ها بر اساس قوانین و الگوریتم‌های مشخص.۳. ثبت نهایی معامله و اعلام نتیجه به بازار.مثال در بورس: در سامانه معاملاتی بورس، هر لحظه هزاران سفارش برای نمادهایی مثل «فولاد» ارسال می‌شود. هسته معاملات دائماً بررسی می‌کند: «آیا خریداری وجود دارد که قیمت پیشنهادی‌اش با پایین‌ترین قیمت فروشنده هم‌خوانی داشته باشد؟» اگر پاسخ مثبت باشد، معامله انجام می‌شود.مثال در ارز دیجیتال: در بایننس، شما سفارش خرید بیت‌کوین روی قیمت ۶۵,۰۰۰ دلار ثبت می‌کنید. هسته معاملات بلافاصله در دفتر سفارشات (Order Book) جستجو می‌کند تا فروشنده‌ای با این قیمت (یا کمتر) پیدا کند و معامله را در لحظه جوش دهد.نکته طلایی: از دید منطق هسته معاملات، «سهام یک شرکت» و «بیت‌کوین» هیچ تفاوتی با هم ندارند؛ هر دو صرفاً متغیرهایی هستند که باید مقادیر عرضه و تقاضای آن‌ها تطبیق داده شود.بخش دوم: اجزای هسته معاملات (کالبدشکافی آشپزخانه)بیایید معماری داخلی این سیستم را با همان مثال رستوران بررسی کنیم:۱. گیت‌وی (Gateway) – پیشخدمت‌های رستورانپیشخدمت سفارش را از مشتری می‌گیرد و اعتبار آن را می‌سنجد (مثلاً آیا مشتری توان پرداخت دارد؟)، سپس آن را در قالبی استاندارد به آشپزخانه می‌فرستد. در سیستم‌های معاملاتی، گیت‌وی‌ها نقش لایه اعتبارسنجی را دارند تا از ورود داده‌های مخرب یا سفارش‌های بدون پشتوانه مالی به هسته مرکزی جلوگیری کنند.۲. توالی‌ساز (Sequencer) – دستگاه نوبت‌دهیتصور کنید جلوی در آشپزخانه دستگاهی قرار دارد که روی هر سفارش یک برچسب زمانی دقیق می‌زند: «شماره ۴۵۳۲، ساعت ۱۰:۳۰:۲۱ و ۵۳۴ نانوثانیه». در دنیای برنامه‌نویسی و شبکه‌های شلوغ، مدیریت درخواست‌های همزمان بسیار حیاتی است. توالی‌ساز تضمین می‌کند که اگر دو نفر دقیقاً در یک لحظه سفارشی ثبت کردند، حق تقدم به صورت عادلانه و بر اساس میکروثانیه‌ها رعایت شود.۳. موتور تطبیق (Matching Engine) – سرآشپز اجرااین بخش، قلب تپنده سیستم است. سرآشپز یخچالی با دو قفسه دارد: قفسه خریداران (Bids) که از بالاترین قیمت مرتب شده، و قفسه فروشندگان (Asks) که از پایین‌ترین قیمت چیده شده است. سرآشپز با سرعتی بی‌نظیر چک می‌کند که آیا بالاترین قیمت خرید با پایین‌ترین قیمت فروش تقاطع دارد یا خیر. تمام این پردازش‌ها در کسری از میکروثانیه انجام می‌شود.۴. سرور توزیع (Distribution Server) – بلندگوی اعلام نتیجهپس از آماده شدن غذا، سرآشپز در بلندگو اعلام می‌کند: «سفارش ۴۵۳۲ انجام شد!» در بازارها، این سرور قیمت‌های جدید و معاملات انجام‌شده را به همه کاربران، کارگزاری‌ها و ربات‌های معامله‌گر مخابره می‌کند تا نمودارها به‌روز شوند.بخش سوم: الگوریتم‌های تطبیق – قوانین آشپزخانهبیشتر بازارهای مالی از یک قانون شفاف و عادلانه به نام اولویت قیمت-زمان (FIFO) استفاده می‌کنند:اولویت اول با بهترین قیمت است: بالاترین قیمت برای خرید، و پایین‌ترین قیمت برای فروش.اولویت دوم با زمان است: اگر دو نفر یک قیمت را پیشنهاد دهند، سفارشی که زودتر در سیستم ثبت شده (توسط توالی‌ساز) جلوتر است.یک مثال مشترک:فرض کنید سه نفر برای خرید یک دارایی سفارش گذاشته‌اند:سفارش الف: قیمت ۱۰۰۰، حجم ۵، زمان ۱۰:۰۰:۰۱سفارش ب: قیمت ۱۰۰۰، حجم ۱۰، زمان ۱۰:۰۰:۰۲سفارش ج: قیمت ۹۹۰، حجم ۲۰، زمان ۱۰:۰۰:۰۰ (با وجود ثبت زودهنگام، قیمت پایین‌تری دارد).اگر یک فروشنده با حجم ۸ واحد و قیمت ۱۰۰۰ وارد بازار شود، سیستم ابتدا ۵ واحد را به «الف» می‌دهد (چون قیمت برابر اما زمان بهتری نسبت به ب دارد) و ۳ واحد باقیمانده را به «ب» اختصاص می‌دهد. سفارش «ج» فعلاً در صف باقی می‌ماند.الگوریتم‌های دیگری مثل Pro-Rata (تسهیم به نسبت) هم وجود دارند که بیشتر در بازارهای مشتقه استفاده می‌شوند و به سفارش‌های حجم بالا، سهم بیشتری تخصیص می‌دهند تا نقدینگی بازار افزایش یابد.بخش چهارم: چرا سرعت اینقدر مهم است؟ (نبرد میکروثانیه‌ها)در بازارهای مالی، تأخیر (Latency) بزرگترین دشمن معامله‌گران است. فرصت‌های آربیتراژ (اختلاف قیمت بین دو بازار) گاهی فقط چند میلی‌ثانیه دوام دارند.در بورس‌های سنتی، شرکت‌های معاملات فرکانس بالا (HFT) هزینه‌های گزافی می‌کنند تا سرورهایشان را در ساختمان خودِ بورس (Co-location) قرار دهند.در بازار کریپتو، ربات‌ها برای شکار اختلاف قیمت بین صرافی‌ها با هم رقابت می‌کنند و تأخیر در پردازش شبکه می‌تواند به معنای از دست رفتن سود باشد.تفاوت کلیدی: در بورس‌های سنتی، پس از انجام معامله، تسویه مالی (جابه‌جایی واقعی پول و سهام) ممکن است یک تا دو روز کاری زمان ببرد. اما در صرافی‌های کریپتو، تسویه همزمان با معامله انجام می‌شود. یعنی هسته معاملات کریپتو فشار مضاعفی را تحمل می‌کند؛ زیرا باید هم‌زمان با تطبیق سفارش، دیتابیس موجودی کیف پول‌ها را نیز در همان لحظه به‌روزرسانی کند.بخش پنجم: امنیت و پایداری – اگر سرآشپز بیمار شود؟اگر هسته معاملات از کار بیفتد، شریان حیات بازار قطع می‌شود.بورس توکیو در سال ۲۰۲۰ به دلیل نقص سخت‌افزاری یک روز کامل تعطیل شد.صرافی بایننس در می ۲۰۲۱ به دلیل هجوم بی‌سابقه کاربران (۱.۶ میلیون سفارش در ثانیه) برای ساعاتی دچار اختلال شد.راه‌حل‌های سیستمی: استفاده از سرورهای پشتیبان (Hot Standby) که همیشه آماده جایگزینی هستند، مکانیزم قطع‌کننده مدار (Circuit Breaker) برای توقف موقت بازار در زمان ریزش‌های هیجانی، و فیلترهای ضد اسپم در لایه گیت‌وی.بخش ششم: آینده – آیا بلاک‌چین جایگزین هسته معاملات می‌شود؟در دنیای دیفای (DeFi)، صرافی‌های غیرمتمرکزی مانند Uniswap از الگوریتمی به نام AMM استفاده می‌کنند که اصلاً نیازی به دفتر سفارش (Order Book) و هسته تطبیق سنتی ندارد. با این حال، برای صرافی‌های بزرگ و متمرکز، هسته‌های کلاسیک با سرعت پردازش سخت‌افزاری (FPGA) همچنان بی‌رقیب هستند. آینده احتمالاً متعلق به سیستم‌های هیبریدی است: تطبیق سفارشات در یک هسته مرکزی سریع، و ثبت نهایی (تسویه) روی شبکه شفاف بلاک‌چین.جمع‌بندی: یک هسته، دو بازارپشت هر کلیک خرید یا فروشی که در بورس یا صرافی کریپتو انجام می‌دهید، یک معماری بی‌نظیر به نام هسته معاملات قرار دارد. با همان اجزای استاندارد (گیت‌وی، توالی‌ساز، موتور تطبیق و توزیع‌کننده) و همان دغدغه‌های همیشگی توسعه‌دهندگان: سرعت، امنیت و پایداری. حالا می‌دانید که در این آشپزخانه دیجیتال، همه‌چیز با دقت نانوثانیه‌ها در حال پخته شدن است.درصورتی که نیاز به طراحی هسته معاملاتی دارید با ما تماس بگیرید.0919 990 6342#هسته_معاملات #MatchingEngine #بورس #بازار_سرمایه #صرافی_ارز_دیجیتال #بایننس #معاملات_فرکانس_بالا #HFT #دفتر_سفارشات #OrderBook #آموزش_بورس #کریپتو #تطبیق_سفارش #الگوریتم_معاملاتی #فناوری_مالی #FinTech #معامله_گری #سرمایه_گذاری #بیت_کوین #اتریوم #آربیتراژ #نقدینگی #گیت_وی #Sequencer #سرور_توزیع #امنیت_بازار #پایداری_سیستم #تسویه_همزمان #بازار_مشتقه #Pro_Rata #اولویت_زمان_قیمت #FIFO #صرافی_غیرمتمرکز #DeFi #Uniswap #AMM #بلاک_چین #Blockchain #معامله_آنلاین #تحلیل_بازار #تکنولوژی_مالی #معماری_سیستم #نانوثانیه #میکروثانیه #Co_location #ربات_معامله_گر #CircuitBreaker #Hot_Standby #توسعه_دهندگان #سرعت_و_امنیت رحیم لطفی رحیم لطفی Fri, 29 May 2026 23:31:13 +0330 https://virgool.io/@m_15490185/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%B3%D9%81%D8%A7%D8%B1%D8%B4%D8%A7%D8%AA-%D9%85%D8%B9%D8%A7%D9%85%D9%84%D8%A7%D8%AA%DB%8C-%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7%DB%8C-%DA%A9%D8%A7%D9%85%D9%84-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%B9%D8%A7%D9%85%D9%84%D9%87-%DA%AF%D8%B1%D8%A7%D9%86-%D8%AA%D8%A7%D8%B2%D9%87-%DA%A9%D8%A7%D8%B1-%D9%88-%D8%AD%D8%B1%D9%81%D9%87-%D8%A7%DB%8C-fpdwuwameaiy اگر به تازگی وارد دنیای معامله‌گری در بازارهای مالی مثل فارکس، بورس یا ارزهای دیجیتال شده باشید، احتمالاً با دکمه‌های «Buy» و «Sell» روبه‌رو شده‌اید و فکر کرده‌اید که کار به همین سادگی است. اما داستان به همینجا ختم نمی‌شود. یکی از مهم‌ترین مهارت‌هایی که هر معامله‌گر باید در خود پرورش دهد، شناخت انواع سفارشات (Orders) و کاربرد هرکدام در شرایط مختلف بازار است.انتخاب نوع سفارش می‌تواند تفاوت بین یک معاملۀ سودآور و یک ضرر سنگین را رقم بزند. در این مقاله، سه نوع اصلی سفارشات – مارکت (Market)، لیمیت (Limit) و استاپ (Stop) – را به زبان ساده بررسی می‌کنیم، مزایا و معایب هرکدام را می‌گوییم و با مثال توضیح می‌دهیم که کجا باید از آنها استفاده کنید.انواع سفارشات معاملاتیسفارش مارکت (Market Order): سرعت، بدون معطلیسفارش مارکت ساده‌ترین نوع سفارش است. وقتی شما یک سفارش مارکت ثبت می‌کنید، در واقع به صرافی یا کارگزار خود می‌گویید: «همین الان و با بهترین قیمتی که در بازار وجود دارد، معامله را انجام بده.» در این نوع سفارش، سرعت اجرا در اولویت قرار دارد، نه قیمت دقیق.مزایای سفارش مارکتاجرای آنی: سفارش تقریباً بلافاصله انجام می‌شود. اگر نیاز دارید سریعاً وارد یک سهم یا ارز شوید یا از آن خارج شوید، این بهترین گزینه است.سادگی: نیاز به تنظیمات خاصی ندارد و برای معامله‌گران مبتدی بسیار راحت است.معایب و ریسک پنهان: لغزش قیمت (Slippage)بزرگ‌ترین عیب سفارش مارکت، پدیده‌ای به نام لغزش قیمت است. فرض کنید قصد خرید یک سهم را دارید و در همان لحظه قیمت پیشنهادی فروشندگان ۱۰۰ تومان است. شما روی دکمه خرید کلیک می‌کنید. اما در آن چند میلی‌ثانیه، قیمت به ۱۰۱ تومان تغییر می‌کند. سفارش مارکت شما روی قیمت ۱۰۱ تومان اجرا می‌شود، چون دستور داده‌اید «به هر قیمتی که هست، الان بخر». این اختلاف همان لغزش قیمت است که در بازارهای پرنوسان می‌تواند کاملاً غافلگیرتان کند.یک مثال واقعی: تصور کنید قیمت لحظه‌ای بیت‌کوین ۶۰,۰۰۰ دلار است و شما با سفارش مارکت اقدام به خرید می‌کنید. اگر در همان لحظه حجم عظیمی از سفارشات خرید وارد بازار شود، ممکن است سفارش شما روی ۶۰,۱۰۰ دلار بنشیند. در یک معاملۀ بزرگ، همین اختلاف کم می‌تواند هزینه زیادی روی دستتان بگذارد.کی استفاده کنیم؟ وقتی سرعت برایتان حیاتی است (مثلاً خبر مهمی منتشر شده و می‌خواهید سریعاً سهمی را بفروشید) و حاضرید ریسک تغییر جزئی قیمت را بپذیرید.سفارش لیمیت (Limit Order): دقت و کنترل کامل بر قیمتاگر سفارش مارکت مثل یک خرید عجولانه از اولین فروشنده است، سفارش لیمیت مثل چانه‌زدن و خرید فقط در قیمت مورد نظر شماست. در سفارش لیمیت، شما یک «حد قیمت» تعیین می‌کنید و می‌گویید: «فقط در صورتی معامله را انجام بده که قیمت به این عدد یا بهتر از آن برسد.»انواع سفارش لیمیتلیمیت خرید (Buy Limit): دستور خرید در قیمتی پایین‌تر از قیمت فعلی بازار. مثلاً اگر دلار ۵۰,۰۰۰ تومان است و شما فکر می‌کنید قیمت به ۴۹,۵۰۰ تومان کاهش پیدا می‌کند و بعد رشد می‌کند، یک سفارش Buy Limit روی ۴۹,۵۰۰ تومان می‌گذارید. اگر بازار به آن سطح برسد، سفارش شما فعال می‌شود.لیمیت فروش (Sell Limit): دستور فروش در قیمتی بالاتر از قیمت فعلی بازار. اگر دلار ۵۰,۰۰۰ تومان است و پیش‌بینی می‌کنید به ۵۱,۰۰۰ تومان برسد و سپس ریزش کند، یک سفارش Sell Limit روی ۵۱,۰۰۰ تومان می‌گذارید تا در سقف بفروشید.مزایا و معایب سفارش لیمیتمزیت اصلی: شما دقیقاً همان قیمتی را که می‌خواهید پرداخت می‌کنید یا دریافت می‌کنید. دیگر خبری از لغزش قیمت نیست.عیب بزرگ: عدم قطعیت در اجرا. هیچ تضمینی نیست که بازار به قیمت تعیین‌شده توسط شما برسد. ممکن است قیمت تا ۴۹,۶۰۰ تومان پایین بیاید و دوباره بالا برود، اما سفارش Buy Limit شما روی ۴۹,۵۰۰ تومان هرگز فعال نشود و شما از یک فرصت عالی جا بمانید.کی استفاده کنیم؟ وقتی تحلیل شما می‌گوید قیمت در یک محدودۀ خاص واکنش نشان می‌دهد و می‌خواهید دقیقاً در همان نقطه وارد شوید، یا وقتی قصد دارید یک دارایی را با سود مشخصی بفروشید (حد سود یا Take Profit).سفارش استاپ (Stop Order): محافظ شما در برابر ضررهای بزرگسفارش استاپ کمی پیچیده‌تر است و عمدتاً برای مدیریت ریسک طراحی شده. این نوع سفارش برخلاف لیمیت که برای ورود یا خروج با قیمت بهتر است، یک ماشه است. شما یک «قیمت فعال‌سازی» (Trigger Price) تعیین می‌کنید. وقتی بازار به آن قیمت رسید، سفارش استاپ شما به یک سفارش مارکت (یا لیمیت در نوع پیشرفته‌تر) تبدیل می‌شود.رایج‌ترین نوع: استاپ لاس (Stop Loss)فرض کنید سهمی را ۱۰۰ تومان خریده‌اید. نمی‌خواهید بیشتر از ۵ تومان ضرر کنید. بنابراین یک سفارش استاپ فروش (Sell Stop) روی قیمت ۹۵ تومان می‌گذارید. تا وقتی قیمت بالای ۹۵ تومان است، هیچ اتفاقی نمی‌افتد. اما به محض اینکه قیمت به ۹۵ تومان سقوط کند، سفارش استاپ شما فعال شده و به یک سفارش مارکت فروش تبدیل می‌شود تا از ضرر بیشتر جلوگیری کند.نکتۀ بسیار مهم درباره استاپ لاس این است که فعال شدن آن به معنای فروش دقیقاً روی ۹۵ تومان نیست. پس از برخورد قیمت به ۹۵ تومان، سفارش با بهترین قیمت موجود در بازار اجرا می‌شود که ممکن است ۹۴.۸۰ تومان باشد. این یعنی در بازارهای بسیار بی‌ثبات، باز هم احتمال لغزش قیمت وجود دارد.حد ضرر تضمینی (Guaranteed Stop)برخی کارگزاران نوعی استاپ لاس ارائه می‌دهند که در ازای دریافت کارمزد بیشتر، اجرای دقیقاً روی قیمت تعیین‌شده را تضمین می‌کند. این گزینه برای مواقعی که نوسانات شدید است (مثلاً زمان اعلام نرخ بهره) یک سپر دفاعی مطمئن است.استاپ لیمیت (Stop-Limit)ترکیبی از دو سفارش قبلی. شما هم قیمت فعال‌سازی و هم قیمت لیمیت را تعیین می‌کنید. وقتی بازار به قیمت فعال‌سازی رسید، یک سفارش لیمیت (نه مارکت) ثبت می‌شود. این روش از لغزش قیمت جلوگیری می‌کند، اما این ریسک را دارد که اگر قیمت به سرعت از محدودۀ لیمیت شما رد شود، سفارش پر نشود و شما همچنان با ضرر شناور بمانید.انتخاب هوشمندانه، معامله‌گری حرفه‌ایشناخت این سه نوع سفارش و استفاده درست از آنها، یکی از خطوط جداکنندۀ یک معامله‌گر مبتدی از یک فرد حرفه‌ای است. یک استراتژی معاملاتی خوب نه تنها به شما می‌گوید چه چیزی بخرید و کی بخرید، بلکه دقیقاً مشخص می‌کند با چه نوع سفارشی وارد بازار شوید و با چه نوع سفارشی خارج شوید.دفعه بعد که پای چارت معاملاتی نشستید، مکث کوتاهی کنید و از خود بپرسید: آیا در این لحظه سرعت برایم مهم‌تر است یا دقت قیمت؟ آیا باید از سودم محافظت کنم یا فقط به دنبال یک فرصت ورود هستم؟ پاسخ به این سوالات، نوع سفارش مناسب را برایتان مشخص خواهد کرد.#سفارشات_معاملاتی #آموزش_معامله‌گری #مارکت_اوردر #لیمیت_اوردر #استاپ_اوردر #مدیریت_ریسک #اسلیپیج #فارکس #بورس #ارز_دیجیتال #معامله‌گری_حرفه‌ای #استراتژی_معاملاتی #حد_ضرر #تحلیل_تکنیکال #سرمایه_گذاری #TradingOrders #MarketOrder #LimitOrder #StopOrder #RiskManagement #Forex #Cryptocurrency #StockMarket #Slippage #TradingStrategy #StopLoss #TechnicalAnalysis #Investment رحیم لطفی رحیم لطفی Sat, 23 May 2026 16:00:49 +0330 https://virgool.io/@m_15490185/%D9%85%D8%B4%D8%A7%D9%88%D8%B1%D9%87-%D8%AA%D8%AE%D8%B5%D8%B5%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%A7-%D8%B1%D8%AD%DB%8C%D9%85-%D9%84%D8%B7%D9%81%DB%8C-zgv3eabjaqv4 ۲۰ سال تجربه در مدیریت فنی، معماری نرم افزار و راهبری پروژه‌های سازمانیهزینه‌های بالای توسعه و نگهداریهزینه‌های سربار توسعه و نگهداری سیستم از بودجه پیش‌بینی شده فراتر رفته است💡 پروژه‌های نرم‌افزاری شما با تأخیر و هزینه‌ی زیاد روبه‌روست؟با مدیریت حرفه‌ای پروژه‌های نرم‌افزاری، زمان تحویل را کوتاه و هزینه‌ها را بهینه کنید.🚀 مشکلات فنی، باگ‌های زیاد و کیفیت پایین سیستم؟ما سیستم شما را پایدار، سریع و بدون خطا می‌سازیم.🎯 راه فنی مشخص ندارید؟با طراحی نقشه‌راه دقیق، تیم توسعه را در مسیر درست قرار دهید.👥 مدیریت فنی ضعیف؟با رهبری مؤثر ما، بهره‌وری تیم‌تان را چند برابر کنید.⚙️ به دنبال مهاجرت به تکنولوژی‌های جدید؟ما مسیر امن و بدون ریسک را برای تحول دیجیتال شما ترسیم می‌کنیم.💸 هزینه‌های توسعه و نگهداری بالا؟با راهکارهای هوشمند ما، هزینه‌ها را کاهش دهید و بازدهی را افزایش دهید.کاهش تأخیر و هزینه پروژه‌های نرم‌افزاریپایان تاخیر در پروژه‌های نرم‌افزاری 🚀کاهش هزینه توسعه سیستمتحویل به‌موقع، بدون خطا و باکیفیتبا مدیریت فنی هوشمند، پروژه‌های نرم‌افزاری خود را سریع‌تر، ارزان‌تر و مطمئن‌تر انجام ده مشاوره تخصصی رایگان.رفع مشکلات فنی و باگ‌های مکررسیستم شما پر از باگ است؟ساخت نرم‌افزار بدون خطا و پایدارکیفیت بالا، تجربه کاربری عالیبا تیم فنی حرفه‌ای ما، مشکلات فنی و خطاهای نرم‌افزاری را برای همیشه برطرف کنید. پشتیبانی ۲۴ ساعته، عملکرد تضمین‌شده.کاهش هزینه‌های نگهداری نرم‌افزارهزینه نگهداری نرم‌افزار زیاد شده؟کاهش هزینه و افزایش بهره‌وری 💰راهکار هوشمند توسعه پایداربا بهینه‌سازی ساختار فنی، هزینه‌های توسعه و نگهداری نرم‌افزار خود را تا ۴۰٪ کاهش دهید.برای همکاری و مشاوره، با ما در تماس باشید:شرکت فرا تاب رایان گستر📞 09199906342📧 lotfirahimdev@gmail.com#توسعه_نرم‌افزار#برنامه_نویسی#طراحی_سایت#اپلیکیشن_موبایل#نرم‌افزار_سفارشی#برون_سپاری#توسعه_چابک#مدیریت_پروژه#تحول_دیجیتال#مشاوره_فناوری#استارتاپ#کسب_و_کار_آنلاین#کارآفرینی#مدیریت_کسب_و_کار#فناوری_اطلاعات#نوآوری#همکاری#تیم_توسعه#استخدام_برنامه‌نویس#خدمات_فناوری#لینکدین#فرا_تاب_رایان_گستر#فراتاب #برون_سپاری_پروژه رحیم لطفی رحیم لطفی Mon, 11 May 2026 13:45:54 +0330 https://virgool.io/@m_15490185/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D9%88-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D8%AF%DB%8C%D8%B2%D8%A7%DB%8C%D9%86-solid-design-principle-%D8%A7%D8%B5%D9%88%D9%84-solid-o5dj5m7usscd اصول SOLID اگرچه همواره پای ثابت بحث‌های برنامه‌نویسی‌اند، اما نقش واقعی‌شان در مسیر توسعه معمولاً نادیده گرفته می‌شود. در این آموزش، رویکرد متفاوتی داریم و کاربرد SOLID را به عنوان یک سنجه و ابزار اعتبارسنجی (Validation) برای ارزیابی طراحی شیءگرا بررسی می‌کنیم.گام‌های سه‌گانه توسعه: از شناخت تا کدنویسی بسیاری از برنامه‌نویسان مستقیماً سراغ نوشتن کد (OOP) می‌روند، در حالی که خلق یک معماری استاندارد نیازمند طی کردن این مراحل است: تحلیل شیءگرا (OOA): درک عمیق نیازمندی‌های بیزینس و صورت‌مسئله. طراحی شیءگرا (OOD): معماری و ساختاربندی راهکارها پیش از شروع برنامه‌نویسی. کدنویسی شیءگرا (OOP): تبدیل طراحی‌های انجام‌شده به کدهای اجرایی. در اینجا یاد می‌گیریم که چطور ساختار اولیه را با الگوهای GRASP پایه‌ریزی کنیم و سپس با ترازوی SOLID، عیار طراحی خود را محک بزنیم. مرز حیاتی میان الگو (Pattern) و اصل (Principle) طراحی تشخیص تفاوت این دو مفهوم، از چالش‌های مهم توسعه‌دهندگان ارشد است:دیزاین پترن‌ها: فرمول‌هایی آماده، شفاف و کپسوله‌شده برای برطرف کردن چالش‌های تکراری‌اند. دیزاین پرینسیپل‌ها: حکم قطب‌نما را دارند و فاقد چارچوب‌های صلب هستند. بررسی می‌کنیم که چرا اجرای اصلی مانند Single Responsibility به بلوغ حرفه‌ای نیاز دارد؛ چرا که افراط در آن به پیچیدگی زاید (Over-engineering) و تفریط در آن به کدهای آشفته ختم می‌شود. معماری در سطوح مختلف: از کانتکست تا کد قواعد طراحی صرفاً به کلاس‌های برنامه محدود نیستند! ما نحوه داشتن یک نگاه کلان و لایه‌محور را آموزش می‌دهیم: کاربرد اصل SRP در مقیاس‌های بزرگ‌تر مانند Bounded Contextها و میکروسرویس‌ها. شیوه‌های کنترل وابستگی‌ها و ارتباطات در لایه‌های Container و Component. تاثیر مدیریت وابستگی در مهار معضلاتی نظیر خشکی نرم‌افزار (Rigidity) و مقاومت در برابر تغییر (Viscosity). اهمیت شناخت وابستگی‌ها (Dependency) پیش از ورود به SOLID مادامی که منشأ اصلی پیچیدگی‌های سیستم (یعنی وابستگی‌ها) را درک نکنید، قواعد سالید صرفاً محفوظاتی بی‌کاربرد خواهند بود. در این ویدیو، پیش‌نیازهای ورود به دنیای معماری حرفه‌ای، نظیر درک الگوهای GRASP و استراتژی‌های مدیریت وابستگی را به شکلی کاربردی کالبدشکافی می‌کنیمویدو این آموزشhttps://www.aparat.com/v/dxq47gdامید وارم لذت ببرید رحیم لطفی رحیم لطفی Fri, 10 Apr 2026 11:58:50 +0330 https://virgool.io/@m_15490185/%D9%81%D8%B1%D8%A7-%D8%AA%D8%A7%D8%A8-%D8%B1%D8%A7%DB%8C%D8%A7%D9%86-%DA%AF%D8%B3%D8%AA%D8%B1-%D8%AC%D8%A7%DB%8C%DB%8C-%DA%A9%D9%87-%D8%A7%DB%8C%D8%AF%D9%87-%D9%87%D8%A7-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D9%85%DB%8C-%D8%B4%D9%88%D9%86%D8%AF-%E2%9C%A8-jmislhae9m0b آیا شرکت شما هم با این چالش مواجه است؟ 🤔"نیروی فنی متخصص به‌اندازه کافی نداریم.""پروژه نرم‌افزاری داریم، اما زمان کافی برای مدیریتش نداریم.""می‌خواهیم روی core business خود تمرکز کنیم."اگر این جمله‌ها برای شما آشناست، جای درستی آمده‌ایدپروژه نرم‌افزاری‌تان را به ما بسپارید 🚀ما در شرکت فرا تاب رایان گستر، پل ارتباطی بین ایده‌های بزرگ و راه‌حل‌های نرم‌افزاری قدرتمند هستیم. اگر شرکت شما به دنبال یک تیم متخصص برای پیاده‌سازی پروژه‌های نرم‌افزاری خود است، ما آماده همکاری با شما هستیم.تخصص ما، توسعه نرم‌افزارهای سفارشی با بالاترین استانداردهای کیفیت است. ما در فرا تاب رایان گستر با استفاده از جدیدترین تکنولوژی‌ها و متدولوژی‌های چابق (Agile)، پروژه شما را از مرحله ایده تا پیاده‌سازی و پشتیبانی همراهی می‌کنیم. چه به دنبال یک تیم توسعه برای پروژه‌های Outsource باشید و چه نیاز به یک شریک بلندمدت برای تحول دیجیتال کسب‌وکار خود داشته باشید، تیم مهندسی ما اینجاست تا با قدرت فنی و تعهد بالا، مسیر موفقیت شما را هموار کند✅ خدمات ما:توسعه نرم‌افزارهای سفارشیبرون‌سپاری تیم فنی (Outsourcing)مشاوره تحول دیجیتال.برای همکاری و مشاوره، با ما در تماس باشید:شرکت فرا تاب رایان گستر📞 09199906342📧 lotfirahimdev@gmail.com#توسعه_نرم‌افزار#برنامه_نویسی#طراحی_سایت#اپلیکیشن_موبایل#نرم‌افزار_سفارشی#برون_سپاری#توسعه_چابک#مدیریت_پروژه#تحول_دیجیتال#مشاوره_فناوری#استارتاپ#کسب_و_کار_آنلاین#کارآفرینی#مدیریت_کسب_و_کار#فناوری_اطلاعات#نوآوری#همکاری#تیم_توسعه#استخدام_برنامه‌نویس#خدمات_فناوری#لینکدین#فرا_تاب_رایان_گستر#فراتاب #برون_سپاری_پروژه رحیم لطفی رحیم لطفی Mon, 23 Feb 2026 01:39:37 +0330 https://virgool.io/@m_15490185/dynamic-aggregate-gcsqesbgiwyu برنامه نویسی امروز تماماً در مورد هزینه ها است. یکی از مهمترین چالش های شرکت های نرم افزاری پرفرمنس می باشد. در بیشتر موارد در زمان طراحی aggregate ها ما بر اساس نیازمندی های اولیه aggregate ها را طراحی می کنیم اما در آینده ممکن است نیازمندی ها تغییر کند و aggregate ها برای جواب دادن به نیاز مندی های آینده زیاد مناسب نباشد و باعث مشکلات پرفرمنس و پیچیده شدن کوئری های شود یا حتی نیاز به لود شدن دیتا های اضافه باشد.و تغییر درaggregate ها ممکن است در بخش های زیادی از برنامه تغییرات انتشار یافته داشته باشد و زمان و هزینه توسعه را بیشتر نمایید. در بعضی موارد بر اساس نوع دیتابیس )SQL Server, MongoDb, ..( شاید نیاز باشد برای موارد پرفرمنسی ترتیب واکشی Entity ها رو درaggregate ها تغییر دهیم یا نیاز باشد بخشی از aggregate لود شود. به عبارتی دیگر یک aggregate برای یک نیاز مندی مناسب و برای نیازمندی های دیگر مناسب نباشد و باعث پیچیدگی در طراحی شود. و در سنارویو های مختلف نیاز به ترکیب و لود شدن aggregate های مختلف باشد. برای جلوگیری از این گونه مشکلات پیشنهاد می شود که aggregate ها را کوچیک طراحی کنیم و میتواند از Dynamic aggregate استفاده نمایید. Dynamic aggregate این امکان را به شما میدهد که aggregate ها را ترکیب و به صورت پویا در زمان اجرا لود نمایید . Dynamic aggregate این امکان را فراهم می کند که بدون تغییر در aggregate های اولیه بتوان دیتا را از aggregate مختلف باز سرعت زیاد لود کنید. در زمان خواندن دیتا های از aggregate های مختلف جهت کم کردن تعداد I/O پیشنهاد می شود از Dynamic aggregate استفاده نمایید.Dynamic Aggregateاگریگیت پویا - Dynamic Aggregateمنبعhttps://github.com/RahimLotfiGH/AUAFramework.Net8_CQRS رحیم لطفی رحیم لطفی Sat, 30 Mar 2024 16:02:59 +0330 https://virgool.io/@m_15490185/%D9%86%DA%A9%D8%A7%D8%AA%DB%8C-%DA%A9%D9%87-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%BE%DB%8C%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%D8%A7%D9%84%DA%AF%D9%88%DB%8C-cqrs-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%AF%D8%B1-%D9%86%D8%B8%D8%B1-%D8%AF%D8%A7%D8%B4%D8%AA-qax07mbiox0u این یک داستان در مورد نکاتی است که در هنگام پیاده سازی الگوی معماری CQRS باید در نظر گرفته شود. این نوشته بر گرفته از تجربیات مختلف در مورد پیاده سازی الگوی CQRS در شرکت های مختلف می باشد. در این نوشته سعی شده است مشکلاتی که در طول پیاده سازی الگوی CQRS برخورد کرده ام، به صورت خلاصه به اشتراک گذاشته شود و امیدوارم این نکات مورد توجه شما قرار بگیرید.1 : مهمترین موضوع در هنگام استفاده کردن از الگوی معماری CQRS این است که هر بیزینسی نیاز به این الگو ندارد به عنوان مثال در بیزنس های بزرگ معمولا یک یا دو میکروسرویس داریم که خیلی نیاز به پیاده سازی الگوی CQRS دارند که معمولا جزو Core Domain بیزینس می باشند. در سایر موارد پیاده سازی CQS کافی می باشد. (منظور بنده استفاده از شدو دیتا یا data redundant برای جلوگیری از ارسال درخواست زیاد و کنترل ترافیک شبکه نیست )2-هنگام پیاده سازی الگوی CQRS اگر شما یک Application داشته باشید که دو کانکشن به دیتابیس های مختلف داشته باشد یعنی شما دو نوع Entity دارید یعنی دو نوع DomainEntity خواهید داشت و دو نوع Repository و دو نوع Service و غیره. از هر چیز در Application دو نوع دارید که برای این جداسازی باید سراغ راهکار های مختلفی بروید که خود باعث پیچیدگی می شود. در هنگامی که دیتابیس های مختلف دارید بهتر است Application برای R/W را جدا کنید .چون باعث پیچیدگی Application می شود.3-در پیازه سازی الگوی CQRS در بیشتر مواقع در زمان انجام عملیات Write شما نیاز به Read های سریع به داده های که همین الان تغییر یافته یا نوشته شده اند دارید و نمی توانید منتظر Sync شدن دیتابیس ها باشید. در این صورت باید از دیتابیس Write برای انجام عملیات Read های لحظه ی نیز استفاده کنید.. اشاره به مورد اول شما دو نوع Read خواهید داشت Read از دیتابیس Read و Read از دیتابیس Write پس بهتر است Application برای R/W را جدا کنید .چون باعث پیچیدگی می شود.4-معولا برای گزارش های پیچیده و محدودی که شاید در پروژهای بزرگ نیز کمتر از 10 مورد باشد (10 عددی تقریبی می باشد) . شما مشکل performance و پیاده سازی الگوی CQRS دارید و از دیتابیس Read باید حتما خوانده شوند و بقیه Read ها مشکل پرفرمنسی ندارند و از همان دیتابیس Write هم می تواند خوانده شوند 5-در الگوی CQRS معمولا دیتابیس های NOSQL برای Read و دیتابیس های SQL برای Write انتخاب می شوند .که این دوتا تکنلوژی مختلف می باشند بهتر است برای جلوگیری از پیچیدگی برنامه از همان ابتدا Application ها جدا طراحی شوند. اپلیکیشن های سبک نگهداری راحت تری دارند. 6- معمولا تعداد درخواست های Read از خواست های Write بیشتر است, (البته به نوع اپلیکیشن وابسته است) . شاید نیاز باشد شما اپلیکشن Read را به تعداد زیاد Scale کنید. درصورتی که در اپلیکیشن Write نیاز به این کار نداشته باشید. پس بهتر است Application برای R/W جدا طراحی شوند.7-نکته ی آخر این که بهتراست در ابتدا اپلیکیشن را برای CQS (یعنی یک دیتابیس ) طراحی کنید. بعد از راه اندازی و عملیاتی شدن نسخه اولیه، می توانید Application برای قسمت read را نیز طراحی نمایید. که از همان اول درگیر مفاهیم پیچیده Outbox و inbox و عملیات Sync نشوید و حتی شاید بعدا نظرتان در مورد روش و الگو های انتخابی تغییر کند.#softwarearchitecture #softwaredevelopment #softwareengineering #softwaredesign #arcitecturepatterns #performance #microservices #microservicesarchitecture #cqrsپیاده سازی الگوی CQRS رحیم لطفی رحیم لطفی Sun, 03 Mar 2024 23:50:38 +0330 https://virgool.io/@m_15490185/lmax-architectur-senq0u43lbfs LMAX (Lightweight, Massively Parallel, and eXtensible) is an architectural style designed for high-performance financial systems, particularly in the context of electronic trading platforms. It was developed by LMAX, a financial exchange based in London, and is known for its low-latency and high-throughput characteristics.Key features of the LMAX architecture include:1. Disruptor Pattern : At the core of the LMAX architecture is the Disruptor pattern, which is a high-performance inter-thread messaging framework. It allows for efficient communication between threads with minimal contention and lock-free operation, reducing latency and improving throughput.2. Event Sourcing : LMAX uses event sourcing as its underlying data model. Instead of storing the current state of an entity, the system maintains a log of events that have occurred over time. This approach can simplify certain aspects of system design and can provide a reliable audit trail.3. Single Threaded Components : LMAX divides the system into single-threaded components, which helps to avoid the complexity and performance issues associated with multi-threading. Each component processes a specific type of event in a single-threaded manner, reducing contention and improving predictability.4. Parallel Processing : While individual components are single-threaded, the LMAX architecture is designed to support parallel processing of events across multiple components. This allows the system to scale horizontally by adding more instances of components, each running on a separate thread or machine.5. Asynchronous I/O : LMAX leverages asynchronous I/O operations to minimize the impact of latency associated with traditional synchronous I/O. This is crucial for high-frequency trading systems where low latency is a critical requirement.6. Memory Mapping : LMAX makes extensive use of memory-mapped files for communication between components. This allows for efficient sharing of data between different parts of the system and can contribute to overall performance improvements.7. Predictable Performance : One of the key goals of LMAX is to provide predictable and consistent performance. This is essential in financial systems where low latency and high throughput are critical, and unpredictable performance can lead to financial losses.The LMAX architecture has been widely regarded as a successful example of how to design high-performance, low-latency systems, especially in the context of financial exchanges. It emphasizes the importance of minimizing contention, maximizing parallelism, and leveraging modern hardware capabilities to achieve optimal performance. رحیم لطفی رحیم لطفی Sat, 03 Feb 2024 01:57:18 +0330 https://virgool.io/@m_15490185/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-lmax-yhrkavmvo0ql معماری LMAXمعماری LMAX یک سبک معماری همروند و قابل گسترش است که برای سیستم‌های مالی با عملکرد بالا طراحی شده است، به ویژه در زمینه‌ی پلتفرم‌های معاملات الکترونیکی. این معماری توسط LMAX، یک صرافی مالی در لندن، توسعه یافته و به دلیل کاهش تاخیر و افزایش ظرفیت، شناخته شده است. با ازستفاده از معماری LMAX میتوان بیش از 6 میلیون سفارش را در یک ثانیه با یک ترد انجام شود. پرفرمنس از مهمترین مشخصه های این معماری می باشد در بازار های مالی مثل فارکس نمونه های از این معماری مشاهده می شود. از دیگر مشخصه های این معماری ساختمان داده Lock Free می باشد.ویژگی‌های کلیدی معماریLMAX عبارتند از:1- الگوی Disruptor: در مرکز معماری LMAX، الگوی Disruptor قرار دارد که یک چارچوب ارتباطی بین‌نخی با عملکرد بالا است. این امکان را فراهم می‌کند که با حداقل رقابت و عملیات بدون قفل، ارتباط کارآمد بین نخ‌ها برقرار شود و تاخیر را کاهش دهد و ظرفیت را افزایش دهد.2- ذخیره‌سازی رویدا: LMAX از مدل داده‌سازی ایونت سورسینگ به عنوان مدل داده اصلی خود استفاده می‌کند. به جای ذخیره وضعیت فعلی یک موجودیت، سیستم یک لاگ از رویدادهایی که در طول زمان رخ داده‌اند را نگه می‌دارد. این رویکرد می‌تواند برخی جنبه‌های طراحی سیستم را ساده‌تر کند و یک ردیابی حسابداری قابل اعتماد فراهم کند.3- اجزاء تک نخی: LMAX سیستم را به اجزاء تک نخی تقسیم می‌کند، که به کاهش پیچیدگی و مسائل عملکردی مرتبط با چند نخ کمک می‌کند. هر جزء یک نوع خاص از رویداد را به صورت تک نخی پردازش می‌کند و این باعث کاهش رقابت و بهبود پیش‌بینی می‌شود.4- پردازش همروند: هرچند اجزاء فردی تک نخی هستند، اما معماری LMAX برای پردازش همروند رویدادها در افق چندین اجزاء طراحی شده است. این امکان را به سیستم می‌دهد که با افزودن نمونه‌های بیشتر از اجزاء، هر کدام در یک نخ یا دستگاه مجزا، مقیاس‌پذیر باشد.5- ورودی/خروجی ناهمگن :LMAX از عملیات ورودی/خروجی ناهمگن برای کاهش تأثیر تاخیر مرتبط با ورودی/خروجی همگن سنتی بهره می‌برد. این امر برای سیستم‌های معاملات با فرکانس بالا که تاخیر کم اهمیت دارد، حیاتی است.6- نگهداری حافظهLMAX از فایل‌های مموری مپ برای ارتباط بین اجزاء استفاده فراوان می‌کند. این امکان را به سیستم می‌دهد تا اطلاعات را به بهترین شکل بین بخش‌های مختلف سیستم به اشتراک بگذارد و به بهبود کلی عملکرد کمک کند.7- عملکرد قابل پیش‌بینی یکی از اهداف اصلی LMAX، ارائه عملکرد قابل پیش‌بینی و مداوم است. این در سیستم‌های مالی که تاخیر کم و ظرفیت بالا اهمیت دارد، حیاتی است و عملکرد پیش‌بینی ناپذیر ممکن است منجر به ضرر مالی شود.معماری LMAX به عنوان یک مثال موفق از چگونگی طراحی سیستم‌های با عملکرد بالا و تاخیر کم، به ویژه در زمینه‌ی صرافی‌های مالی، شناخته می‌شود. این معماری بر اهمیت کاهش رقابت، بیشینه کردن همرون رحیم لطفی رحیم لطفی Sat, 03 Feb 2024 01:53:53 +0330 https://virgool.io/@m_15490185/aspnet-unique-architecture-lv5appz5cxcb Abstract Software projects require constant changes and updates. If the structure develops in the wrong way, it will prevent changes and extensions, and most of the time will lead to task duplication or rewriting of the project from scratch. To get rid of the complexity and task duplication that most programmers and developers face, which is also caused by the inconsistency of code at different levels of the program, we need a simple consistent structure for writing software projects so that we can hide some of the complexity and focus on business of the task. For example, the Bootstrap framework is a very useful framework for Front End, but few people would prefer to use frameworks like Bootstrap for design, and write all of their design with CSS from the beginning. For the Back End section, however, a simple, general-purpose framework can save time and cost and produce high-quality code and a uniform architecture. This framework allows developers to develop their projects based on an appropriate integrated pattern. The framework must be flexible enough to allow the programmer to apply any changes needed, relying on its robust structureWhy Framework? One of the problems of software companies is the lack of the right structure for developing their projects. As a result, they have often produced such complex and nested codes that creating changes in one part of the project severely affects or disrupts other parts. Therefore, lack of the right structure for development makes it impossible to update the previous code and reduces the efficiency of the team to almost zero. The reason for this is the difference in coding and lack of structure and architecture. The development team must first agree on a set of rules and structures. Architectural patterns are not the result of a programmer's experiences; they have resulted from the experiences of hundreds of programmers and design professionals over years. These frameworks are not innovations or inventions, but are feedbacks on redesign and recoding that programmers have been involved with in order to achieve the highest levels of flexibility, extensibility and reusability. Their use makes the produced codes more simple, flexible and extensible. The use of a framework can help us save time and cost and make it easier to document and maintain the system.Asp.Net Unique Architecture (AUA) Framework Using the AUA ( Asp.Net Unique Architecture ) Framework, you can easily have better, faster, and more orderly and focused coding. This framework is based on new and up-to date concepts, structures and architectures, including: Clean Architecture, Clean Code, Domain-driven design (DDD), Lmax Architecture , SOLID Principle, Code Refactoring, GRASP (object-oriented design principle)AUA is a simple, lightweight framework for producing projects of any size (small and large). It can be applied in all architectures (Micro service, CQRS, etc.) due to its transparency in structure. It is also full of different design patterns, thus a great source for software architects and developers. Domain Driven Design (DDD) EF 6 and EF Core 3.0,3.1 The ability to develop software in a simple and fast way Based on SOLID Principles Modular design Layered architecture AUA Framework's Versions: Asp.Net MVC (.net framework and ef6) Asp.Net MVC Core 3.0,3.1 Asp.Net Web API Core 3.0,3.1 Asp.net 5Minimum benefits of using the AUA framework• Reducing the software development costs, • Saving time, • Convenient maintenance, • Quality productReferenceshttps://auaframework.com رحیم لطفی رحیم لطفی Fri, 29 Oct 2021 14:39:57 +0330 https://virgool.io/@m_15490185/%D9%86%D8%AD%D9%88%D9%87-%D9%86%D8%B5%D8%A8-%D9%88-%D8%B1%D8%A7%D9%87-%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%DB%8C-%D9%81%D8%B1%DB%8C%D9%85-%D9%88%D8%B1%DA%A9-aspnet-unique-architecture-aua-hn0yfza4n15o سیستم‌های نرم‌افزاری ساخته می‌شوند تا اهداف تجاری سازمان‌ها را برآورده کنند و معماری پلی بین این اهداف تجاری و سیستم نهایی ایجاد می‌کند. افزایش پیچیدگی در طراحی و تولید سیستم‌های نرم‌افزاری، علاوه بر بالا رفتن هزینه و زمان موجب تولید سیستم‌هایی با کیفیت پایین و خطاهای زمان اجرای زیاد می‌شود. برای غلبه‌بر مشکل پیچیدگی سیستم‌های نرم‌افزاری و نیز کاهش خطا درکد تولید شده، استفاده از فریم ورک‌ها توصیه می‌شود.داشتن یک ساختار خوب باعث افزایش سرعت تیم می‌شود.تجربه‌ی نشان داده است داشتن یک ساختار حتی اگر بهترین هم نباشد اما از نداشتن ساختار و تولید کد‌های در هم تنیده و دست وپنجه نرم کردن با هزاران جزئیات..  نتیجه بهتری میدهد.فریم ورک AUA به صورت کدباز و نسخه‌های اولیه آن رایگان می‌باشد. ستفاده ازفریم ورک  AUA موجب صرفه جویی در زمان و هزینه می‌شود و همچنین امکان توسعه‌ی نرم افزار به شکلی ساده و سریع، را فراهم می‌کند. با کمک فریم ورک AUA آیوآ می‌توان به راحتی کدنویسی بهتر، سریع تر، منظم‌تر و با تمرکز بالاتری داشته باشیم. این فریم ورک بر اساس مفاهیم، ساختار‌ها و معماری‌های جدید و به روز نوشته شده است .در این مقاله هدف این است که فریم وک AUA را نصب و راه اندازی کنیم.مراحل نصب و راه اندازی فریم ورک Asp.Net Unique Architecture  (AUA)1-دانلود AUA فریمورکاز لینک دانلود شما می توانید نسخه‌ی mvc یا Api  فریمورک را دانلود کنید .(یا از ریپازیتوری گیت دریافت کنید)2- بعد از خارج کردن از حالت فشرده و باز کردن با ویژوال استدیو پروژه را باز کنید و حتما بیلد کنید شابد کمی طول بکشد که طبیعی می‌باشد و کتابخانه‌های nuget را دانلود میکند برای اولین بار این کتابخانه‌ها را نیاز دارد.3- برای تنظم کانکشن استرینگ به فابل appsettings.Development.json  رفته و کانکشن استرینگ را تغییر دهید (در صورت نیاز)WebApi folder > AUA.ProjectName.WebApi > appsettings.json > appsettings.Development.json4 - در این مرحله باید مای گریشن  add-migration   کنیم که دیتابیس ساخته شود.وارد Tools > NuGet Package Manager > Package Manager Console میشویم.دقت داشته باشید که لایه  AUA.ProjectName.DataLayer انتخاب شده باشد که dbContext  در این لایه می‌باشد.ودستور  زیر را اجرا نماییدPM> Add-Migration init-auaPM> Update-Databaseبعد از ساخته شدن دیتابیس شما می توانید پروژه را اجرا و خروجی مورد نظر متناسب با نوع پروژه WebApi  یا MVC   ببینید.نام کاربری پیشفرض Admin و رمز عبور 123  می‌باشد.WebApiMVCموفق و پیروز باشید. رحیم لطفی رحیم لطفی Sun, 24 Oct 2021 19:32:19 +0330 https://virgool.io/@m_15490185/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D9%81%D8%B1%DB%8C%D9%85-%D9%88%D8%B1%DA%A9-aspnetunique-architecure-aua-ypffvgle1uv8 پروژه های نرم افزاری، نیازمند تغییرات و بروزرسانی های مداوم هستند. در صورتی که ساختار توسعه درست نباشد مانع از تغییرات و گسترش می شود و در بیشتر مواقع باعث انجام کار های اضافه یا باز نویسی پروژه از اول می شود. برای رهایی از پیچیدگی و انجام کارهای تکراری که عمدتا برنامه نویسان و توسعه دهندگان با آن روبرو هستند که این امر نیز ناشی از عدم همخوانی کد ها در سطوح مختلف برنامه می باشد، ما نیاز مند یک ساختار یکپارچه و ساده جهت نوشتن پروژه های نرم افزاری هستیم که با کمک آن بتوان بخشی از پیچیدگی را مخفی و روی بیزینس کار تمرکز نمود. برای مثال فریم ورک Bootstrap یک فریم ورک بسیار مفید برای Front End می باشد که کمتر کسی ترجیح میدهد برای طراحی از فریم ورک هایی مثل Bootstrap استفاده نکند و از ابتدا تمام طراحی خود را با CSS بنویسد. برای قسمت End Back نیز این گونه است که یک فریم ورک ساده و همه منظوره می تواند در زمان و هزینه صرفه جویی کند و باعث تولید کد با کیفیت بالا و یک معماری یک نواخت شود. فریم ورک به توسعه دهندگان این امکان را می دهد تا بر اساس الگوی مناسب و یکپارچه پروژه خود را توسعه دهند. فریم ورک باید از انعطاف پذیری بالایی برخوردار باشد تا برنامه نویس بتواند با تکیه بر ساختار قدرتمند آن هر گونه تغییر مورد نیاز را اعمال کند.چرا فریم ورک؟سیستم‌های نرم‌افزاری ساخته‌ می‌شوند تا اهداف تجاری سازمان‌ها را برآورده کنند و معماری پلی بین این اهداف تجاری و سیستم نهایی ایجاد می‌کند. افزایش پیچیدگی در طراحی و تولید سیستم‌های نرم‌افزاری، علاوه بر بالا رفتن هزینه و زمان موجب تولید سیستم‌هایی با کیفیت پایین و خطاهای زمان اجرای زیاد می‌شود. برای غلبه‌بر مشکل پیچیدگی سیستم‌های نرم‌افزاری و نیز کاهش خطا درکد تولید شده، استفاده از فریم ورک ها توصیه می‌شود.یکی از مشکلات شرکت های نرم افزاری، نداشتن ساختار درست برای توسعه پروژه های خود می باشد. در نتیجه در بیشتر مواقع کد های پیچیده و در هم تنیده را تولید نموده اند که ایجاد تغییر در یک بخش از پروژه، بخش های دیگر را بشدت تحت تاثیر قرار داده یا از کار می اندازد. بنابر این نداشتن ساختار درست برای توسعه امکان به روز رسانی کد های قبلی را غیر ممکن و بهره وری تیم را تقریبا به صفر می رساند.دلیل این امر نیز تفاوت در نحوه ی کد نویسی و نداشتن ساختار و معماری می باشد. در ابتدای کار باید تیم توسعه بر روی یک سری قوانین و ساختار های توافق کند. الگوهای معماری نتایج تجربیات یک برنامه نویس نیست، بلکه حاصل تجربیات صدها برنامه نویس و طراحی حرفه ای است که در طول سال های بسیار به دست آمده اند. فریم ورک ابداع شده یا اختراع شده نیست، بلکه بازخورد طراحی ها و کد نویسی های مجدد است که برنامه نویسان در پروژه های مختلف برای کسب بیشترین انعطاف پذیری، توسعه پذیری و قابلیت استفاده ی مجدد با آن ها درگیر بوده اند.استفاده از فریم ورک باعث می شود که کد های تولید شده ساده، انعطاف پذیر و قابلیت گسترش بیشتری داشته باشند. با استفاده از فریم ورک می توان در زمان و هزینه صرفه جویی کرد و همچنین مستند سازی و نگهداری سیستم نیز آسانتر می شود.فریم ورک(AUA) Asp.Net Unique Architectureاستفاده ازفریم ورک AUA موجب صرفه جویی در زمان و هزینه می شود و همچنین امکان توسعه ی نرم افزار به شکلی ساده و سریع، را فراهم می کند. با کمک فریم ورک AUA آیوآ می توان به راحتی کدنویسی بهتر، سریع تر، منظم تر و با تمرکز بالاتری داشته باشیم. این فریم ورک بر اساس مفاهیم، ساختار ها و معماری های جدید و به روز نوشته شده استAUA یک فریم ورک ساده و سبک برای تولید پروژه های با هر مقیاس (کوچک و بزرگ) می باشد. فریم ورک Asp.Net Unique Architecture به دلیل شفافیت در ساختار، قابل استفاده در تمام معماری های (Micro service، CQRS,، ... (می باشد. همچنین فریم ورک AUA پر از الگو های طراحی مختلف بوده که یک منبع بسیار خوب برای معماران نرم افزار و توسعه دهنده ها می باشد.نسخه دات نت 5 فریم ورک AUA را میتوانید از لینک زیر دانلود کنیدلینک ویدوهای آموزشی فارسی و انگلیسیhttps://auaframework.com/Document/VideoTutorialلینک مستقیم فریم ورک AUAhttps://auaframework.com/Website/DownloadBasicPackageلینک ریپازیتوری https://github.com/Heilton/AUAFrameWorkلینک مستنداتhttps://auaframework.com/Document رحیم لطفی رحیم لطفی Thu, 21 Oct 2021 01:21:23 +0330