From 6fdfac9f03fa515cecf0cb9fcfa7aeeedda0aa98 Mon Sep 17 00:00:00 2001 From: Meghdad <61308304+MeghdadFadaee@users.noreply.github.com> Date: Wed, 22 Jul 2026 13:10:37 +0330 Subject: [PATCH] cleanup bank-flow.md --- docs/bank-flow.md | 1521 ++++++++++++++++++++------------------------- 1 file changed, 676 insertions(+), 845 deletions(-) diff --git a/docs/bank-flow.md b/docs/bank-flow.md index e25f326..112dd1a 100644 --- a/docs/bank-flow.md +++ b/docs/bank-flow.md @@ -1,872 +1,703 @@ -BankFlow Challenge 2026 -۱.مقدمه -در این چالش شما مسئول طراحی و پیادهسازی یک سامانه Backend برای پردازش درخواستهای تسهیالت بانکی خواهید بود. هدف این چالش صرراا نوشرنن چند API یا پیادهسرازی یک سرری قابلیت مشرص نیسرت بلکه اننظار میرود راهکاری ارائه کنیدً که از نظر طراحی نرماازار، قابلیت توسرهه، خوانایی کد و نگهداری، کیفیت مناسریی داشرنه باشرد.در این مسرابقه عالوه بر صرتت عملکرد سیسنم، کیفیت تصمیمهای مهندسی شما نیز مورد ارزیابی قرار خواهد گرات. -بنابراین مهماری سریسرنم، نتوه مدلسرازی ارآیندها، تفکیک مسرئولیتها و قابلیت توسرهه راهکار، به اندازه عملکرد صرتی آن اهمیت دارد. -۲.داسنان مسئله -شررکت داتین یکی از ارائهدهندگان زیرسراختهای بانکی (Provider Service Banking (اسرت و سرروی های مصنلفی را در اخنیار بانکها و مؤسرسرات مالی قرار میدهدً.یکی از متصروتت این شررکت، سرامانه پردازش درخواسرت تسرهیالت اسرت.روزانه هزاران درخواسرت وام از بانکهای مصنلف وارد این سرامانه میشرود.هر درخواسرت باید قیل از تأیید نهایی، مراحل مصنلفی را طی کند. -به عنوان نمونه: -ثیت درخواست -↓ -اعنیارسنجی اولیه -↓ -بررسی تقلب -↓ -اعنیارسنجی مالی -↓ -تأیید مدیر -↓ -تأیید نهایی -اما تمام بانکها ارآیند یکسانی ندارند. -برای مثال: -بانک اول -اعنیارسنجی -↓ -بررسی تقلب -↓ -اعنیارسنجی مالی -↓ -تأیید -بانک دوم -اعنیارسنجی -↓ -بررسیAML -↓ -بررسی تقلب -↓ -بررسی ضامن -↓ -اعنیارسنجی مالی -↓ -تأیید -بانک سوم -اعنیارسنجی -↓ -تأیید مدیر -↓ -تأیید -مدیریت شرکت تصمیم گرانه است نسصه دوم این سامانه را با تمرکز بر توسههپذیری و نگهداری آسان طراحی کند. شما به عنوان تیم توسهه مسئول طراحی این نسصه جدید هسنید. -۳.هدف چالش -هدف این چالش طراحی و پیادهسرازی یک **سرامانه پردازش درخواسرت تسرهیالت** اسرت که بنواند ارآیند بررسری درخواسرتهای وام را مدیریت کند. -سامانه باید امکان موارد زیر را اراهم کند: -ثیت درخواست تسهیالت -پردازش درخواست بر اساسWorkflow -مشاهده وضهیت اهلی درخواست --مشاهده تاریصچه پردازش درخواست -در این چالش تنها پیادهسازی قابلیتها مالک ارزیابی نیست. -اننظار میرود راهکار ارائه شده دارای ویژگیهای زیر باشد: -طراحی مناسب -قابلیت توسهه -قابلیت نگهداری -خوانایی مناسب -قابلیت تست -تفکیک صتی مسئولیتها -۴.متدوده مسئله -در این مسابقه تنها مسئولیت شما پیادهسازی **سامانه پردازش درخواست تسهیالت** است. -تمام سروی ها و قابلیتهایی که خارج از این متدوده قرار دارند، جزئی از این چالش متسوب نمیشوند. -##قابلیتهای الزامی -راهکار شما باید حداقل قابلیتهای زیر را پیادهسازی کند: -ثیت درخواست تسهیالت -اجرای ارآیند بررسی درخواست -مدیریت وضهیت درخواست -ثیت تاریصچه اجرای مراحل -نگهداری اطالعات پ ازRestart -ارائهAPI هایREST -اجرای پروژه از طریقDocker -##موارد خارج از متدوده -پیادهسازی موارد زیر الزامی نیست: -احراز هویت کاربران --مدیریت نقشها و سط دسنرسی -رابط کاربری(Frontend( -اتصال واقهی به سامانههای بانکی -ارسال پیامک --ارسال ایمیل -- Kubernetes - -اسنقرار رویCloud -- CI/CD - Microserviceمهماری - ها Message Brokerسایر یا- Kafka، RabbitMQ - -پردازش توزیعشده - در صورت اسنفاده از این اناوریها امنیاز اضااهای تهلق نصواهد گرات. - ۵.نیازمندیهای عملکردی - سامانه باید قابلیتهای زیر را ارائه دهد. - -1FR ##ثیت درخواست تسهیالت - کاربر باید بنواند یک درخواست جدید ثیت کند. - برای هر درخواست، سامانه باید یک شناسه یکنا تولید کند. - پ از ثیت مواق، وضهیت اولیه درخواست برابر خواهد بود با: - SUBMITTED - و اولین مرحله پردازش: - VALIDATION - -2FR ##پردازش درخواست - سامانه باید ارآیند بررسی درخواست را اجرا کند. - اجرای ارآیند تا زمانی ادامه پیدا میکند که درخواست به یکی از وضهیتهای نهایی زیر برسد: MANUAL_REVIEWًًیا REJECTEDًًیا APPROVED - -3FR ##مشاهده اطالعات درخواست - کاربر باید بنواند اطالعات اهلی یک درخواست را مشاهده کند. - حداقل اطالعات قابل نمایش عیارتاند از: - شناسه درخواست - اطالعات ثیتشده - وضهیت اهلی - مرحله اهلی - زمان ایجاد - زمان آخرین تغییر - -4FR ##مشاهده تاریصچه پردازش - کاربر باید بنواند تاریصچه اجرای مراحل مصنلف را مشاهده کند. - برای هر مرحله اجرا شده، حداقل اطالعات زیر باید ذخیره شود: - نام مرحله - ننیجه اجرا - زمان اجرا - -علت یا توضی ننیجه - تاریصچه باید به ترتیب زمانی نمایش داده شود. - Workflowاجرای## FR-5 - هر درخواست باید از چند مرحله پردازش عیور کند. - هر مرحله تنها مسئول انجام یک وظیفه مشص است. - برای مثال: - مرحله اعنیارسرنجی تنها وظیفه بررسری صرتت اطالعات ورودی را دارد و نیاید مسرئول بررسری اعنیار مالی یا تشرصی تقلب باشد. - -6FR ##مدیریت وضهیت - هر درخواست در هر لتظه تنها یک وضهیت جاری دارد. - تغییر وضهیتها باید قابل پیشبینی و مطابق قوانین Workflow باشد. - وجود چند وضهیت همزمان برای یک درخواست مجاز نیست. - -7FR ##ماندگاری اطالعات - اطالعات درخواستها باید پ از Restart شدن برنامه نیز حفظ شوند. - حداقل اطالعات زیر باید ذخیره شوند: - اطالعات درخواست - وضهیت اهلی - مرحله اهلی - -تاریصچه اجرای مراحل - روش ذخیرهسازی اطالعات بر عهده شرکتکننده است. - اسنفاده صرف از حااظه (Storage Memory-In (این نیازمندی را برآورده نمیکند. - -8FR ##بازیابی پ ازRestart - در صورت راهاندازی مجدد برنامه، درخواستهایی که قیال ثیت شدهاند باید همچنان قابل مشاهده و پردازش باشند. Restartشدن برنامه نیاید باعث از بین رانن اطالعات شود. ---- --9FR ##جلوگیری از پردازش تکراری -اگر عملیات پردازش یک درخواست بیش از یک بار اجرا شود، سیسنم نیاید: --مراحل قیلی را مجددا اجرا کند. --تاریصچه تکراری ایجاد کند. -وضهیت نهایی درخواست را تغییر دهد. --10FR ##توسههپذیری -یکی از مهمترین اهداف این چالش، طراحی سیسنمی است که در آینده بنوان به سادگی مراحل یا قوانین جدیدی به آن اضااه کرد. ارض کنید بانک در آینده بصواهد: --مرحله جدیدی به Workflow اضااه کند. --ترتیب اجرای مراحل را تغییر دهد. --قوانین تصمیمگیری جدید تهریف کند. -مهماری سامانه باید به گونهای باشد که اعمال این تغییرات نیازمند بازنویسی گسنرده سیسنم نیاشد. پیادهسازی این قابلیتها در این مرحله الزامی نیست اما طراحی باید از چنین توسهههایی پشنییانی کند. -۶. #اننظارات کیفی -راهکار ارائه شده عالوه بر صتت عملکرد، باید از نظر کیفیت پیادهسازی نیز قابل قیول باشد. -در طراحی سامانه اننظار میرود موارد زیر رعایت شوند: -خوانایی مناسب کد -تفکیک مسئولیتها -وابسنگی کم بین بصشهای مصنلف --قابلیت تست -قابلیت توسهه --قابلیت نگهداری -اسنفاده ازPattern Design ها اجیاری نیست. -واقها مشکلی از طراحی را حل کند. اسنفاده از یک Pattern تنها زمانی ارزشمند است که پیچیدگی بیشنر، به مهنی کیفیت باتتر نیست. -۷. #آزادی در اننصاب اناوری -شرکتکنندگان در اننصاب زبان برنامهنویسی ،Framework ،پایگاه داده و ابزارهای توسهه کامال آزاد هسنند. اسنفاده از اناوری خاص، امنیاز مثیت یا منفی ایجاد نصواهد کرد. -کیفیت راهکار مهمتر از اناوری اننصاب شده است. -۸.اقالم قابل تتویل -هر تیم باید موارد زیر را تتویل دهد: -هدف فایل -Source Code پیادهسازی -اجرای پروژه Dockerfile -راهنمای اجرا md.README -مهرای مهماری md.DESIGN -تتلیل و تصمیمهای مهندسی md.DECISIONS_ENGINEERING -اسنراتژی و پوشش تستها md.TESTING -در صورت نیاز میتوانید اایلهای تکمیلی نیز اضااه کنید. -۹.نکات پایانی -این چالش به گونهای طراحی شده است که بیش از آنکه یک مسئله الگورینمی باشد، یک مسئله مهندسی نرماازار است. راهحل واحدی برای این مسئله وجود ندارد. -شرکتکنندگان باید با تتلیل مسئله، مناسبترین طراحی را اننصاب کرده و بنوانند از تصمیمهای مهندسی خود دااع کنند. ۱۰.مدل دامنه(Model Domain( -در این چالش، هر درخواسرت تسرهیالت یک موجودیت (Entity (مسنقل متسوب میشود که در طول چرخه عمر خود، از مراحل مصنلف Workflow عیور میکند. -هر درخواست حداقل شامل اطالعات زیر است. -|ایلد | نوع | توضی | -|------|------|------| -| String | loanId| شناسه یکنای درخواست )توسط سیسنم تولید میشود(| -| String | customerId| شناسه مشنری| -| Integer | amount| میلغ درخواست| -| String | phone| شماره تلفن همراه| -| Enum | loanType| نوع تسهیالت| -| Integer | monthlyIncome| درآمد ماهانه| -| Integer | creditScore| امنیاز اعنیاری| -| Boolean | hasGuarantor| وجود یا عدم وجود ضامن| -| Enum | status| وضهیت اهلی درخواست| -Workflow |اهلی مرحله |currentStage | Enum | -| Timestamp | createdAt| زمان ایجاد| -| Timestamp | updatedAt| آخرین زمان تغییر| ---- -##انواع تسهیالت -در این نسصه تنها دو نوع تسهیالت تهریف شده است. -BUSINESSًو PERSONAL -در آینده ممکن است انواع دیگری نیز اضااه شوند. -۱۱.وضهیتهای سیسنم(Status Loan( -هر درخواست در هر لتظه دقیقا یکی از وضهیتهای زیر را دارد. -|وضهیت | توضی | -|---------|---------| -| SUBMITTED| درخواست ثیت شده است| . -| PROGRESS_IN| درخواست در حال پردازش است| . -| REVIEW_MANUAL| نیاز به بررسی دسنی دارد| . -| APPROVED| درخواست تأیید شده است| . -| REJECTED| درخواست رد شده است| . -پ از ورود به وضهیتهای APPROVED یا ،REJECTED پردازش خاتمه مییابد. -۱۲.مراحلWorkflow -سیسنم باید حداقل مراحل زیر را پشنییانی کند. -|مرحله | مسئولیت| -|---------|----------| -| VALIDATION| بررسی صتت اطالعات ورودی| -| CHECK_FRAUD| بررسی تقلب| -| CHECK_GUARANTOR| بررسی وجود ضامن| -| CHECK_CREDIT| بررسی اعنیار مالی| -| APPROVAL_MANAGER| تأیید مدیر| -| REVIEW_MANUAL| بررسی دسنی| -هر مرحله اقط مسئول یک وظیفه است. -منطق دو مرحله نیاید داخل یک کالس یا ماژول پیادهسازی شود. -۱۳.ننیجه اجرای هر مرحله -هر مرحله تنها یکی از ننایج زیر را تولید میکند. -PASS -FAIL -MANUAL_REVIEW -در صورت FAIL پردازش منوقف شده و وضهیت نهایی برابر REJECTED خواهد بود. در صورت REVIEW_MANUAL درخواست وارد وضهیت REVIEW_MANUAL میشود. -Workflow ۱۴.پایه -تمام درخواستها از مسیر زیر آغاز میشوند. -SUBMITTED -↓ -VALIDATION -اگر VALIDATION مواق باشد -↓ -FRAUD_CHECK -در غیر این صورت -↓ -REJECTED -۱۵.قوانین اعنیارسنجی(Validation( -مرحله VALIDATION حداقل باید قوانین زیر را بررسی کند. ##شناسه مشنری -الزامی است. -نیاید خالی باشد. -##میلغ -باید بزرگتر از صفر باشد. -در غیر این صورت -INVALID_AMOUNT -##شماره تلفن -الزامی است. -باید: -۱۱ -رقم باشد. --با 09 شروع شود. -اقط شامل رقم باشد. -در غیر این صورت -INVALID_PHONE -##نوع تسهیالت -اقط یکی از مقادیر زیر مجاز است. -PERSONAL -BUSINESS -##درآمد ماهانه -نیاید منفی باشد. -##امنیاز اعنیاری -باید بین 0 تا1000ً باشد -اگر هر یک از قوانین بات نقض شود، ننیجه مرحله VALIDATION برابر FAIL خواهد بود. -۱۶.قوانین بررسی تقلب(Check Fraud( -به منظور جلوگیری از وابسنگی به سروی های خارجی، رانار این مرحله به صورت Mock تهریف شده است. اگر customerId با عیارت زیر شروع شود -FRAUD -ننیجه مرحله -FAIL -خواهد بود. -اگر customerId با عیارت -REVIEW -شروع شود -ننیجه -MANUAL_REVIEW -خواهد بود. -در سایر موارد -PASS -۱۷.مسیرهای شرطیWorkflow -Workflowاین سامانه خطی نیست. -مسیر پردازش بر اساس اطالعات درخواست تغییر میکند. -##درخواستPERSONAL -VALIDATION -↓ -FRAUD_CHECK -↓ -CREDIT_CHECK -↓ -APPROVED -در صورتی که میلغ از حد مشصصی بیشنر باشد ↓ -MANAGER_APPROVAL -##درخواستBUSINESS -VALIDATION -↓ -FRAUD_CHECK -↓ -GUARANTOR_CHECK -↓ -CREDIT_CHECK -↓ -APPROVED -۱۸.بررسی ضامن -این مرحله اقط برای وامهای BUSINESS اجرا میشود. اگر -hasGuarantor == false -ننیجه مرحله FAIL خواهد بود.در غیر این صورت PASS ۱۹.اعنیارسنجی مالی -این مرحله بر اساس creditScore تصمیم میگیرد. -اگر -creditScore < 500 -↓ -FAIL -اگر -500 <= creditScore < 650 -↓ -MANUAL_REVIEW -اگر -creditScore >= 650 -↓ -PASS -۲۰.تأیید مدیر -اگر میلغ درخواست از حد تهیین شده بیشنر باشد، مرحله تأیید مدیر اجرا میشود. در این نسصه مقدار پیشارض این حد برابر است با 500000000 این مقدار باید قابل تغییر باشد. -رانار Mock مدیر -اگر -amount > monthlyIncome × 20 -↓ -FAIL -در غیر این صورت -↓ -PASS -۲۱.نمودار کاملWorkflow +# چالش BankFlow 2026 -۲۲.قابلیت توسهه -در طراحی سیسنم ارض کنید در آینده بانک اعالم کند: -CHECK_AML بهد ازًCHECK_FRAUD اجرا شررود. یا CHECK_LEGALًبرای وامهای BUSINESS اضررااه شود. یا SCORE_RISK قیل از CHECK_CREDIT اجرا شود. -پیادهسازی این مراحل در نسصه اهلی الزامی نیست. -اما مهماری سیسنم باید به گونهای باشد که اضااه شدن چنین مرحلههایی نیازمند بازنویسی گسنرده منطق اصلی سیسنم نیاشد. -۲۳.رانار مورد اننظار در بررسی دسنی -اگر هر مرحله ننیجه REVIEW_MANUALًبرگرداند: --پردازش منوقف میشود. --وضهیت درخواست برابر REVIEW_MANUAL خواهد شد. --مرحله اهلی خاتمه مییابد. --اجرای مجدد Workflow نیاید بدون تصمیم جدید ادامه پیدا کند. -در این نسصه پیادهسازی سیسنم بررسی دسنی الزامی نیست. -۲۴.پیکربندی قوانین کسبوکار(Configuration Rules Business( -یکی از اهداف این چالش، طراحی سامانهای است که تغییر قوانین کسبوکار بدون نیاز به تغییر کدهای اصلی امکانپذیر باشد. به همین منظور، بصشی از قوانین سیسنم باید از طریق اایل پیکربندی قابل تنظیم باشند. -پیادهسازی این اایل میتواند با هر ارمنی انجام شود برای مثال: -- JSON -- YAML -- TOML -- Properties - -هر ارمت مشابه دیگر - ارمت اایل به اننصاب تیم است. - ##حداقل قوانین قابل پیکربندی - سامانه باید حداقل از تنظیمات زیر پشنییانی کند. - ###حداقل امنیاز اعنیاری قابل قیول - minimumCreditScore - نمونه: - json - { - "minimumCreditScore": 650 - } - در صورت تغییر مقدار این پارامنر، سیسنم نیاید نیازمند تغییر کد باشد. - ###سقف نیاز به تأیید مدیر - managerApprovalThreshold - نمونه - json - { - "managerApprovalThreshold": 500000000 - } - در صورت تغییر این مقدار، مسیر Workflow باید به صورت خودکار تغییر کند. - ###ضریب بررسی درآمد - در مرحله Approval Manager رابطه زیر اسنفاده میشود: - amount > monthlyIncome × incomeMultiplier - مقدار ضریب باید قابل تنظیم باشد. - نمونه: - json - { - "incomeMultiplier": 20 - } - ###حداقل امنیاز برای بررسی دسنی - نمونه: - json - { - "manualReviewMinScore": 500, - "manualReviewMaxScore": 649 - } - در صورت تغییر این بازه، رانار سیسنم باید بدون تغییر کد اصالح شود. - ##نکات - تمام مقادیر اوق باید در زمان راهاندازی برنامه خوانده شوند. - در این نسصه نیازی به Reload شدن اایل در زمان اجرا وجود ندارد. - ۲۵.اایل نمونه - نمونه اایل - rules.json - json - { - "minimumCreditScore":650, - "managerApprovalThreshold":500000000, - "incomeMultiplier":20, - "manualReview":{ - "minScore":500, - "maxScore":649 - } - } - Requirement ۲۶.جدید - منطق سیسنم نیاید شامل اعداد ثابت (Numbers Magic (باشد. - مسنقیما در کد نوشنه شوند. برای مثال موارد زیر نیاید - java - if(score>=650) - یا - java - if(amount>500000000) - یا - java - if(score>=500 && score<650) - این مقادیر باید از اایل پیکربندی خوانده شوند. - ۲۷.قابلیت توسهه - ارض کنید بانک در آینده اایل زیر را ارسال کند. - json - { - "minimumCreditScore":700, - "managerApprovalThreshold":900000000, - "incomeMultiplier":15, - "manualReview":{ - "minScore":650, - "maxScore":699 - } - } - در این حالت اننظار میرود رانار سامانه بدون تغییر کد و تنها با تغییر اایل پیکربندی اصالح شود. ۲۸.متدودیت - هدف این بصش پیادهسازی یک Engine Rule عمومی نیست. - شرکتکنندگان تنها کاای است قوانین تهریفشده در این مسنند را از اایل پیکربندی بصوانند و در تصمیمگیری سیسنم اسنفاده کنند. پیادهسازی Language Rule ،DSL یا Engine Rule اخنصاصی امنیاز اضااهای نصواهد داشت. - ۲۹.قراردادAPI - تمامAPI ها باید از اسناندارد REST پیروی کنند. - ارمت تیادل دادهها باید JSON باشد. - تمام پاسخها باید دارای Header زیر باشند. - Content-Type: application/json - ۳۰. #ایجاد درخواست تسهیالت -## Endpoint -http -POST /api/v1/loans -## Request Body -json -{ -"customerId": "C-1001", -"amount": 400000000, -"phone": "09121234567", -"loanType": "PERSONAL", -"monthlyIncome": 50000000, -"creditScore": 720, -"hasGuarantor": false -} -##توضی ایلدها -|ایلد | الزامی | توضی | -|------|---------|---------| -| customerId| بله | شناسه مشنری| -| amount| بله | میلغ درخواست| -| phone| بله | شماره موبایل| -BUSINESS |یا | PERSONAL بله |loanType | -| monthlyIncome| بله | درآمد ماهانه| -| creditScore| بله | امنیاز اعنیاری| -| hasGuarantor| بله | وجود ضامن| -## Response -http -201 Created -json -{ -"loanId":"L-10001", -"status":"SUBMITTED", -"currentStage":"VALIDATION" -} -##خطاها -در صورتی که JSON ارسالی قابل Parse نیاشد: -http -400 Bad Request -json -{ -"error":"INVALID_REQUEST" -} -نکنه: -اعنیارسنجی مقادیر) مانند amount یا (phone داخل Workflow انجام میشود و نیاید باعث خطای 400 شود. -۳۱.اجرایWorkflow -## Endpoint -http -POST /api/v1/loans/{loanId}/process -##توضی -این API باید پردازش درخواست را از مرحله اهلی آغاز کند. -پردازش تا رسیدن به یکی از وضهیتهای زیر ادامه پیدا میکند. +## ۱. مقدمه + +در این چالش، شما مسئول طراحی و پیاده‌سازی یک سامانه Backend برای پردازش درخواست‌های تسهیلات بانکی هستید. هدف صرفاً نوشتن چند API یا پیاده‌سازی مجموعه‌ای از قابلیت‌های مشخص نیست؛ انتظار می‌رود راهکاری ارائه کنید که از نظر طراحی نرم‌افزار، توسعه‌پذیری، خوانایی کد و نگهداری، کیفیت مناسبی داشته باشد. + +علاوه بر صحت عملکرد سیستم، کیفیت تصمیم‌های مهندسی شما نیز ارزیابی خواهد شد. بنابراین معماری سیستم، نحوه مدل‌سازی فرایندها، تفکیک مسئولیت‌ها و توسعه‌پذیری راهکار، به‌اندازه عملکرد صحیح آن اهمیت دارد. + +## ۲. داستان مسئله + +شرکت داتین یکی از ارائه‌دهندگان زیرساخت‌های بانکی (Banking Service Provider) است و سرویس‌های مختلفی را در اختیار بانک‌ها و مؤسسات مالی قرار می‌دهد. یکی از محصولات این شرکت، سامانه پردازش درخواست تسهیلات است. + +روزانه هزاران درخواست وام از بانک‌های مختلف وارد این سامانه می‌شود. هر درخواست باید پیش از تأیید نهایی، مراحل مختلفی را طی کند. برای نمونه: + +```text +ثبت درخواست + ↓ +اعتبارسنجی اولیه + ↓ +بررسی تقلب + ↓ +اعتبارسنجی مالی + ↓ +تأیید مدیر + ↓ +تأیید نهایی +``` + +تمام بانک‌ها فرایند یکسانی ندارند. برای مثال: + +| بانک | فرایند نمونه | +| --- | --- | +| بانک اول | اعتبارسنجی ← بررسی تقلب ← اعتبارسنجی مالی ← تأیید | +| بانک دوم | اعتبارسنجی ← بررسی AML ← بررسی تقلب ← بررسی ضامن ← اعتبارسنجی مالی ← تأیید | +| بانک سوم | اعتبارسنجی ← تأیید مدیر ← تأیید | + +مدیریت شرکت تصمیم گرفته است نسخه دوم این سامانه را با تمرکز بر توسعه‌پذیری و نگهداری آسان طراحی کند. شما به‌عنوان تیم توسعه، مسئول طراحی این نسخه جدید هستید. + +## ۳. هدف چالش + +هدف، طراحی و پیاده‌سازی یک **سامانه پردازش درخواست تسهیلات** است که بتواند فرایند بررسی درخواست‌های وام را مدیریت کند. + +سامانه باید امکانات زیر را فراهم کند: + +- ثبت درخواست تسهیلات؛ +- پردازش درخواست بر اساس Workflow؛ +- مشاهده وضعیت فعلی درخواست؛ +- مشاهده تاریخچه پردازش درخواست. + +راهکار ارائه‌شده باید ویژگی‌های زیر را داشته باشد: + +- طراحی مناسب؛ +- توسعه‌پذیری و نگهداری آسان؛ +- خوانایی مناسب؛ +- قابلیت تست؛ +- تفکیک صحیح مسئولیت‌ها. + +## ۴. محدوده مسئله + +تنها مسئولیت شما پیاده‌سازی **سامانه پردازش درخواست تسهیلات** است. سرویس‌ها و قابلیت‌های خارج از این محدوده، بخشی از چالش محسوب نمی‌شوند. + +### قابلیت‌های الزامی + +- ثبت درخواست تسهیلات؛ +- اجرای فرایند بررسی درخواست؛ +- مدیریت وضعیت درخواست؛ +- ثبت تاریخچه اجرای مراحل؛ +- نگهداری اطلاعات پس از راه‌اندازی مجدد برنامه؛ +- ارائه REST API؛ +- اجرای پروژه از طریق Docker. + +### موارد خارج از محدوده + +پیاده‌سازی موارد زیر الزامی نیست: + +- احراز هویت و مجوزدهی کاربران؛ +- مدیریت نقش‌ها و سطوح دسترسی؛ +- رابط کاربری؛ +- اتصال واقعی به سامانه‌های بانکی؛ +- ارسال پیامک، ایمیل یا اعلان؛ +- Message Brokerهایی مانند Kafka و RabbitMQ؛ +- Redis، Kubernetes و استقرار ابری؛ +- CI/CD؛ +- معماری Microservice؛ +- پردازش یا تراکنش توزیع‌شده؛ +- CQRS و Event Sourcing؛ +- سامانه واقعی بررسی دستی. + +استفاده از این فناوری‌ها امتیاز مستقیم یا اضافی ایجاد نمی‌کند. + +## ۵. نیازمندی‌های عملکردی + +### FR-1: ثبت درخواست تسهیلات + +کاربر باید بتواند یک درخواست جدید ثبت کند. سامانه باید برای هر درخواست، شناسه‌ای یکتا تولید کند. + +پس از ثبت موفق، وضعیت اولیه و نخستین مرحله پردازش به‌ترتیب زیر خواهند بود: + +```text +status: SUBMITTED +currentStage: VALIDATION +``` + +### FR-2: پردازش درخواست + +سامانه باید فرایند بررسی درخواست را اجرا کند. پردازش تا زمانی ادامه پیدا می‌کند که درخواست به یکی از وضعیت‌های نهایی زیر برسد: + +- `APPROVED` +- `REJECTED` +- `MANUAL_REVIEW` + +### FR-3: مشاهده اطلاعات درخواست + +کاربر باید بتواند حداقل اطلاعات زیر را مشاهده کند: + +- شناسه درخواست؛ +- اطلاعات ثبت‌شده؛ +- وضعیت فعلی؛ +- مرحله فعلی؛ +- زمان ایجاد؛ +- زمان آخرین تغییر. + +### FR-4: مشاهده تاریخچه پردازش + +برای هر مرحله اجراشده، حداقل اطلاعات زیر باید ذخیره و به‌ترتیب زمانی نمایش داده شود: + +- نام مرحله؛ +- نتیجه اجرا؛ +- زمان اجرا؛ +- علت یا توضیح نتیجه. + +### FR-5: اجرای Workflow + +هر درخواست باید از چند مرحله پردازش عبور کند. هر مرحله فقط مسئول انجام یک وظیفه مشخص است. برای مثال، مرحله اعتبارسنجی فقط صحت اطلاعات ورودی را بررسی می‌کند و نباید مسئول بررسی اعتبار مالی یا تشخیص تقلب باشد. + +### FR-6: مدیریت وضعیت + +هر درخواست در هر لحظه دقیقاً یک وضعیت جاری دارد. تغییر وضعیت‌ها باید قابل پیش‌بینی و مطابق قوانین Workflow باشد. + +### FR-7: ماندگاری اطلاعات + +حداقل اطلاعات زیر باید پس از راه‌اندازی مجدد برنامه حفظ شوند: + +- اطلاعات درخواست؛ +- وضعیت فعلی؛ +- مرحله فعلی؛ +- تاریخچه اجرای مراحل. + +روش ذخیره‌سازی بر عهده شرکت‌کننده است. استفاده صرف از حافظه (`In-Memory Storage`) این نیازمندی را برآورده نمی‌کند. + +### FR-8: بازیابی پس از راه‌اندازی مجدد + +درخواست‌هایی که پیش‌تر ثبت شده‌اند، باید پس از راه‌اندازی مجدد برنامه همچنان قابل مشاهده و پردازش باشند. + +### FR-9: جلوگیری از پردازش تکراری + +اگر عملیات پردازش یک درخواست بیش از یک بار فراخوانی شود، سامانه نباید: + +- مراحل قبلی را دوباره اجرا کند؛ +- تاریخچه تکراری ایجاد کند؛ +- وضعیت نهایی درخواست را تغییر دهد. + +### FR-10: توسعه‌پذیری + +معماری سامانه باید به‌گونه‌ای باشد که افزودن مرحله جدید، تغییر ترتیب مراحل یا تعریف قوانین تصمیم‌گیری جدید، به بازنویسی گسترده سیستم نیاز نداشته باشد. پیاده‌سازی این قابلیت‌های آینده در نسخه فعلی الزامی نیست، اما طراحی باید از آن‌ها پشتیبانی کند. + +## ۶. انتظارات کیفی + +در طراحی سامانه، موارد زیر باید رعایت شوند: + +- خوانایی مناسب کد؛ +- تفکیک مسئولیت‌ها؛ +- وابستگی کم میان بخش‌های مختلف؛ +- قابلیت تست، توسعه و نگهداری. + +استفاده از Design Patternها اجباری نیست. یک الگو فقط زمانی ارزشمند است که مسئله‌ای واقعی را حل کند؛ پیچیدگی بیشتر لزوماً به‌معنای کیفیت بالاتر نیست. + +## ۷. آزادی در انتخاب فناوری + +شرکت‌کنندگان در انتخاب زبان برنامه‌نویسی، Framework، پایگاه داده، ORM و ابزارهای توسعه کاملاً آزاد هستند. فناوری انتخاب‌شده به‌خودی‌خود امتیاز مثبت یا منفی ندارد؛ کیفیت راهکار مهم‌تر است. + +## ۸. مدل دامنه + +هر درخواست تسهیلات یک موجودیت مستقل (`Entity`) است که در طول چرخه عمر خود از مراحل مختلف Workflow عبور می‌کند. + +هر درخواست حداقل شامل اطلاعات زیر است: + +| فیلد | نوع | توضیح | +| --- | --- | --- | +| `loanId` | `String` | شناسه یکتای درخواست که سیستم تولید می‌کند | +| `customerId` | `String` | شناسه مشتری | +| `amount` | `Integer` | مبلغ درخواست | +| `phone` | `String` | شماره تلفن همراه | +| `loanType` | `Enum` | نوع تسهیلات | +| `monthlyIncome` | `Integer` | درآمد ماهانه | +| `creditScore` | `Integer` | امتیاز اعتباری | +| `hasGuarantor` | `Boolean` | وجود یا عدم وجود ضامن | +| `status` | `Enum` | وضعیت فعلی درخواست | +| `currentStage` | `Enum\|null` | مرحله فعلی Workflow | +| `createdAt` | `Timestamp` | زمان ایجاد | +| `updatedAt` | `Timestamp` | زمان آخرین تغییر | + +### انواع تسهیلات + +در این نسخه، فقط دو نوع تسهیلات تعریف شده است: + +- `PERSONAL` +- `BUSINESS` + +ممکن است در آینده انواع دیگری افزوده شوند. + +## ۹. وضعیت‌های درخواست + +هر درخواست در هر لحظه دقیقاً یکی از وضعیت‌های زیر را دارد: + +| وضعیت | توضیح | +| --- | --- | +| `SUBMITTED` | درخواست ثبت شده است | +| `IN_PROGRESS` | درخواست در حال پردازش است | +| `MANUAL_REVIEW` | درخواست به بررسی دستی نیاز دارد | +| `APPROVED` | درخواست تأیید شده است | +| `REJECTED` | درخواست رد شده است | + +پس از ورود به یکی از وضعیت‌های `APPROVED`، `REJECTED` یا `MANUAL_REVIEW`، پردازش خودکار متوقف می‌شود. + +## ۱۰. مراحل Workflow + +سامانه باید حداقل مراحل زیر را پشتیبانی کند: + +| مرحله | مسئولیت | +| --- | --- | +| `VALIDATION` | بررسی صحت اطلاعات ورودی | +| `FRAUD_CHECK` | بررسی تقلب | +| `GUARANTOR_CHECK` | بررسی وجود ضامن | +| `CREDIT_CHECK` | بررسی اعتبار مالی | +| `MANAGER_APPROVAL` | تأیید مدیر | + +هر مرحله فقط مسئول یک وظیفه است و منطق دو مرحله نباید در یک کلاس یا ماژول پیاده‌سازی شود. + +## ۱۱. نتیجه اجرای مراحل + +هر مرحله یکی از نتایج زیر را تولید می‌کند: + +- `PASS` +- `FAIL` +- `MANUAL_REVIEW` + +در صورت `FAIL`، پردازش متوقف و وضعیت درخواست `REJECTED` می‌شود. در صورت `MANUAL_REVIEW`، پردازش متوقف و وضعیت درخواست `MANUAL_REVIEW` می‌شود. + +## ۱۲. Workflow پایه و مسیرهای شرطی + +تمام درخواست‌ها از مسیر زیر آغاز می‌شوند: + +```text +SUBMITTED → VALIDATION → FRAUD_CHECK +``` + +اگر `VALIDATION` یا `FRAUD_CHECK` با شکست مواجه شود، درخواست رد خواهد شد. + +### درخواست PERSONAL + +```text +VALIDATION + ↓ +FRAUD_CHECK + ↓ +CREDIT_CHECK + ↓ +[در صورت عبور مبلغ از حد تعیین‌شده: MANAGER_APPROVAL] + ↓ APPROVED -REJECTED -MANUAL_REVIEW -## Response -http -200 OK -json +``` + +### درخواست BUSINESS + +```text +VALIDATION + ↓ +FRAUD_CHECK + ↓ +GUARANTOR_CHECK + ↓ +CREDIT_CHECK + ↓ +[در صورت عبور مبلغ از حد تعیین‌شده: MANAGER_APPROVAL] + ↓ +APPROVED +``` + +## ۱۳. قوانین اعتبارسنجی + +مرحله `VALIDATION` حداقل باید قوانین زیر را بررسی کند: + +| فیلد | قانون | کد خطا | +| --- | --- | --- | +| `customerId` | الزامی و غیرخالی | `INVALID_CUSTOMER_ID` | +| `amount` | عددی بزرگ‌تر از صفر | `INVALID_AMOUNT` | +| `phone` | دقیقاً ۱۱ رقم، شروع با `09` و فقط شامل رقم | `INVALID_PHONE` | +| `loanType` | یکی از مقادیر `PERSONAL` یا `BUSINESS` | `INVALID_LOAN_TYPE` | +| `monthlyIncome` | عددی نامنفی | `INVALID_MONTHLY_INCOME` | +| `creditScore` | عددی بین ۰ تا ۱۰۰۰ | `INVALID_CREDIT_SCORE` | + +اگر یکی از قوانین نقض شود، نتیجه مرحله `VALIDATION` برابر `FAIL` خواهد بود. + +## ۱۴. قوانین بررسی تقلب + +برای جلوگیری از وابستگی به سرویس‌های خارجی، رفتار مرحله `FRAUD_CHECK` به‌صورت Mock تعریف می‌شود: + +| شرط | نتیجه | +| --- | --- | +| `customerId` با `FRAUD` آغاز شود | `FAIL` | +| `customerId` با `REVIEW` آغاز شود | `MANUAL_REVIEW` | +| سایر موارد | `PASS` | + +## ۱۵. بررسی ضامن + +مرحله `GUARANTOR_CHECK` فقط برای تسهیلات `BUSINESS` اجرا می‌شود: + +| شرط | نتیجه | +| --- | --- | +| `hasGuarantor == false` | `FAIL` | +| `hasGuarantor == true` | `PASS` | + +## ۱۶. اعتبارسنجی مالی + +مرحله `CREDIT_CHECK` بر اساس `creditScore` و مقادیر فایل پیکربندی تصمیم می‌گیرد: + +| شرط پیش‌فرض | نتیجه | +| --- | --- | +| `creditScore < 500` | `FAIL` | +| `500 <= creditScore < 650` | `MANUAL_REVIEW` | +| `creditScore >= 650` | `PASS` | + +## ۱۷. تأیید مدیر + +اگر مبلغ درخواست از `managerApprovalThreshold` بیشتر باشد، مرحله `MANAGER_APPROVAL` اجرا می‌شود. مقدار پیش‌فرض این حد `500000000` است و باید قابل پیکربندی باشد. + +رفتار Mock مدیر به‌صورت زیر است: + +| شرط | نتیجه | +| --- | --- | +| `amount > monthlyIncome × incomeMultiplier` | `FAIL` | +| سایر موارد | `PASS` | + +## ۱۸. رفتار بررسی دستی + +اگر هر مرحله نتیجه `MANUAL_REVIEW` برگرداند: + +- پردازش متوقف می‌شود؛ +- وضعیت درخواست `MANUAL_REVIEW` می‌شود؛ +- `currentStage` برابر `null` قرار می‌گیرد؛ +- اجرای مجدد Workflow بدون تصمیم جدید نباید ادامه پیدا کند. + +پیاده‌سازی سامانه بررسی دستی در این نسخه الزامی نیست. + +## ۱۹. پیکربندی قوانین کسب‌وکار + +قوانین زیر باید از طریق یک فایل پیکربندی با قالبی مانند JSON، YAML، TOML یا Properties قابل تنظیم باشند: + +- حداقل امتیاز اعتباری قابل قبول؛ +- بازه امتیاز بررسی دستی؛ +- سقف نیاز به تأیید مدیر؛ +- ضریب بررسی درآمد. + +قالب فایل به انتخاب تیم است. تمام مقادیر باید هنگام راه‌اندازی برنامه خوانده شوند و نیازی به بارگذاری مجدد فایل در زمان اجرا نیست. + +نمونه فایل `rules.json`: + +```json { -"loanId":"L-10001", -"status":"APPROVED", -"currentStage":null + "minimumCreditScore": 650, + "managerApprovalThreshold": 500000000, + "incomeMultiplier": 20, + "manualReview": { + "minScore": 500, + "maxScore": 649 + } } -اگر وضهیت برابر REVIEW_MANUALًباشد -json +``` + +منطق سیستم نباید شامل Magic Numberهای مربوط به این قوانین باشد. برای مثال، مقادیر زیر نباید مستقیماً در کد نوشته شوند: + +```java +if (score >= 650) { /* ... */ } +if (amount > 500000000) { /* ... */ } +if (score >= 500 && score < 650) { /* ... */ } +``` + +اگر فایل پیکربندی به‌شکل زیر تغییر کند، رفتار سامانه باید بدون تغییر کد اصلاح شود: + +```json { -"loanId":"L-10001", -"status":"MANUAL_REVIEW", -"currentStage":null + "minimumCreditScore": 700, + "managerApprovalThreshold": 900000000, + "incomeMultiplier": 15, + "manualReview": { + "minScore": 650, + "maxScore": 699 + } } -اگر شناسه وجود نداشنه باشد -http -404 Not Found -json +``` + +هدف این بخش، پیاده‌سازی یک Rule Engine عمومی نیست. کافی است قوانین تعریف‌شده در این سند از فایل پیکربندی خوانده و در تصمیم‌گیری سیستم استفاده شوند. پیاده‌سازی DSL یا Rule Engine اختصاصی امتیاز اضافی ندارد. + +## ۲۰. قرارداد API + +تمام APIها باید از استاندارد REST پیروی کنند. قالب تبادل داده‌ها JSON است و تمام پاسخ‌ها باید Header زیر را داشته باشند: + +```http +Content-Type: application/json +``` + +### ۲۰.۱. ایجاد درخواست تسهیلات + +```http +POST /api/v1/loans +``` + +#### بدنه درخواست + +```json { -"error":"LOAN_NOT_FOUND" + "customerId": "C-1001", + "amount": 400000000, + "phone": "09121234567", + "loanType": "PERSONAL", + "monthlyIncome": 50000000, + "creditScore": 720, + "hasGuarantor": false } -۳۲.رانار اجرای مجددProcess -قیال APPROVED یا REJECTED یاًREVIEW_MANUALًشده باشد، اجرای مجدد اگر درخواست process/ POST نیاید باعث اجرای دوباره Workflow شود. پاسخ باید وضهیت اهلی را برگرداند. -۳۳.دریاات اطالعات درخواست -## Endpoint -http +``` + +تمام فیلدهای فوق الزامی هستند. + +#### پاسخ موفق + +```http +HTTP/1.1 201 Created +``` + +```json +{ + "loanId": "L-10001", + "status": "SUBMITTED", + "currentStage": "VALIDATION" +} +``` + +اگر JSON ارسالی قابل Parse نباشد: + +```http +HTTP/1.1 400 Bad Request +``` + +```json +{ + "error": "INVALID_REQUEST" +} +``` + +اعتبارسنجی مقادیری مانند `amount` و `phone` داخل Workflow انجام می‌شود و نباید باعث پاسخ HTTP 400 شود. + +### ۲۰.۲. اجرای Workflow + +```http +POST /api/v1/loans/{loanId}/process +``` + +پردازش از مرحله فعلی آغاز می‌شود و تا رسیدن به یکی از وضعیت‌های `APPROVED`، `REJECTED` یا `MANUAL_REVIEW` ادامه پیدا می‌کند. + +#### پاسخ + +```http +HTTP/1.1 200 OK +``` + +```json +{ + "loanId": "L-10001", + "status": "APPROVED", + "currentStage": null +} +``` + +نمونه پاسخ برای بررسی دستی: + +```json +{ + "loanId": "L-10001", + "status": "MANUAL_REVIEW", + "currentStage": null +} +``` + +اگر شناسه وجود نداشته باشد: + +```http +HTTP/1.1 404 Not Found +``` + +```json +{ + "error": "LOAN_NOT_FOUND" +} +``` + +اگر درخواست قبلاً به وضعیت `APPROVED`، `REJECTED` یا `MANUAL_REVIEW` رسیده باشد، اجرای مجدد این Endpoint نباید Workflow را دوباره اجرا کند و باید وضعیت فعلی را برگرداند. + +### ۲۰.۳. دریافت اطلاعات درخواست + +```http GET /api/v1/loans/{loanId} -## Response -json +``` + +#### پاسخ + +```json { -"loanId":"L-10001", -"customerId":"C-1001", -"amount":400000000, -"phone":"09121234567", -"loanType":"PERSONAL", -"monthlyIncome":50000000, -"creditScore":720, -"hasGuarantor":false, -"status":"APPROVED", -"currentStage":null, -"createdAt":"2026-07-15T10:00:00Z", -"updatedAt":"2026-07-15T10:00:03Z" + "loanId": "L-10001", + "customerId": "C-1001", + "amount": 400000000, + "phone": "09121234567", + "loanType": "PERSONAL", + "monthlyIncome": 50000000, + "creditScore": 720, + "hasGuarantor": false, + "status": "APPROVED", + "currentStage": null, + "createdAt": "2026-07-15T10:00:00Z", + "updatedAt": "2026-07-15T10:00:03Z" } -اگر شناسه وجود نداشنه باشد -http -404 -json -{ -"error":"LOAN_NOT_FOUND" -} -۳۴.دریاات تاریصچه پردازش -## Endpoint -http +``` + +اگر شناسه وجود نداشته باشد، پاسخ `404 Not Found` با کد `LOAN_NOT_FOUND` برگردانده می‌شود. + +### ۲۰.۴. دریافت تاریخچه پردازش + +```http GET /api/v1/loans/{loanId}/history ---- -## Response -json +``` + +#### پاسخ + +```json [ -{ -"stage":"VALIDATION", -"result":"PASS", -"timestamp":"2026-07-15T10:00:00Z", -"reason":"SUCCESS" -}, -{ -"stage":"FRAUD_CHECK", -"result":"PASS", -"timestamp":"2026-07-15T10:00:01Z", -"reason":"SUCCESS" -}, -{ -"stage":"CREDIT_CHECK", -"result":"PASS", -"timestamp":"2026-07-15T10:00:02Z", -"reason":"SUCCESS" -} + { + "stage": "VALIDATION", + "result": "PASS", + "timestamp": "2026-07-15T10:00:00Z", + "reason": "SUCCESS" + }, + { + "stage": "FRAUD_CHECK", + "result": "PASS", + "timestamp": "2026-07-15T10:00:01Z", + "reason": "SUCCESS" + }, + { + "stage": "CREDIT_CHECK", + "result": "PASS", + "timestamp": "2026-07-15T10:00:02Z", + "reason": "SUCCESS" + } ] -##ترتیب خروجی -تاریصچه باید بر اساس زمان اجرا مرتب شود. -هر Stage اقط یک بار ثیت میشود. -۳۵. Health Check -## Endpoint -http +``` + +تاریخچه باید بر اساس زمان اجرا مرتب شود و هر Stage فقط یک بار ثبت شود. + +### ۲۰.۵. Health Check + +```http GET /health -## Response -http -200 OK -json +``` + +```http +HTTP/1.1 200 OK +``` + +```json { -"status":"UP" + "status": "UP" } -۳۶.ارمت زمان -تمامTimestamp ها باید مطابق اسناندارد زیر باشند. -ISO-8601 UTC -نمونه +``` + +## ۲۱. قالب زمان + +تمام Timestampها باید مطابق استاندارد ISO 8601 و در منطقه زمانی UTC باشند: + +```text 2026-07-15T10:00:00Z -۳۷.کدهای خطا -سیسنم حداقل باید از کدهای زیر اسنفاده کند. -| Code| توضی | -|--------|------------| -|نامهنیر |INVALID_REQUEST | JSON -| FOUND_NOT_LOAN| شناسه درخواست وجود ندارد| -| AMOUNT_INVALID| میلغ نامهنیر| -| PHONE_INVALID| شماره موبایل نامهنیر| -| ID_CUSTOMER_INVALID| شناسه مشنری نامهنیر| -| TYPE_LOAN_INVALID| نوع وام نامهنیر| -| SCORE_CREDIT_INVALID| امنیاز اعنیاری نامهنیر| -|نامهنیر درآمد |INVALID_MONTHLY_INCOME | -۳۸.قراردادPersistence -پ از Restart برنامه، اطالعات زیر باید بدون تغییر باقی بمانند. -اطالعات درخواست -وضهیت اهلی --مرحله اهلی --تاریصچه مراحل -راهکار ذخیرهسازی آزاد است. -۳۹.قراردادDocker -پروژه باید تنها با دسنورات زیر قابل اجرا باشد. -bash +``` + +## ۲۲. کدهای خطا + +سامانه حداقل باید از کدهای زیر استفاده کند: + +| کد | توضیح | +| --- | --- | +| `INVALID_REQUEST` | JSON نامعتبر است | +| `LOAN_NOT_FOUND` | شناسه درخواست وجود ندارد | +| `INVALID_AMOUNT` | مبلغ نامعتبر است | +| `INVALID_PHONE` | شماره موبایل نامعتبر است | +| `INVALID_CUSTOMER_ID` | شناسه مشتری نامعتبر است | +| `INVALID_LOAN_TYPE` | نوع وام نامعتبر است | +| `INVALID_CREDIT_SCORE` | امتیاز اعتباری نامعتبر است | +| `INVALID_MONTHLY_INCOME` | درآمد ماهانه نامعتبر است | + +## ۲۳. توسعه‌پذیری Workflow + +فرض کنید بانک در آینده تغییرات زیر را درخواست کند: + +- اجرای `AML_CHECK` پس از `FRAUD_CHECK`؛ +- افزودن `LEGAL_CHECK` برای تسهیلات `BUSINESS`؛ +- اجرای `RISK_SCORE` پیش از `CREDIT_CHECK`؛ +- افزودن نوع جدیدی از تسهیلات؛ +- تعریف Workflowهای متفاوت برای بانک‌ها. + +پیاده‌سازی این موارد در نسخه فعلی الزامی نیست، اما افزودن آن‌ها نباید به بازنویسی گسترده منطق اصلی سیستم نیاز داشته باشد. + +## ۲۴. قرارداد Docker + +پروژه باید فقط با دستورهای زیر قابل Build و اجرا باشد: + +```bash docker build -t bankflow . -سپ -bash docker run -p 8080:8080 bankflow -سروی باید حداکثر ظرف ۶۰ ثانیه آماده پاسخگویی شود. -۴۰.ساخنار اایلهای تتویلی -حداقل اایلهای زیر باید وجود داشنه باشند. -project/ project/ -│ -├── src/ -├── Dockerfile -├── README.md -├── DESIGN.md -├── ENGINEERING_DECISIONS.md -└── TESTING.md -۴۱. README.md -READMEباید شامل موارد زیر باشد. -روشBuild -روش اجرا -روش اجرای تستها --توضی کوتاه ساخنار پروژه --وابسنگیهای اصلی -# ۴۲. DESIGN.md -حداکثر سه صفته. -این سند باید حداقل به پرسشهای زیر پاسخ دهد. -Workflow ۱-چگونه مدل شده است؟ -۲-مرحله بهد چگونه اننصاب میشود؟ -۳-برای اضااه شدن Stage جدید چه تغییری تزم است؟ -۴-قوانین کسبوکار چگونه از اایل تنظیمات خوانده میشوند؟ -۵-اطالعات چگونه ذخیره میشوند؟ -۶-اگر سیسنم اردا بصواهد CHECK_AML اضااه کند چه تغییراتی تزم است؟ ۷-سه تصمیم مهم طراحی خود را توضی دهید. -۸-مهمترینoff-Trade های طراحی شما چه بوده است؟ ---- -۴۳. #متدودیتها -اسنفاده از اناوریهای زیر اخنیاری است و امنیاز مسنقیمی ندارد. -- Kafka -- RabbitMQ -- Redis -- Microservice -- Kubernetes -- CQRS -- Event Sourcing - امنیاز بر اساس کیفیت راهکار داده میشود، نه پیچیدگی اناوریهای اسنفاده شده. - ۴۴. #مسنند تصمیمهای مهندسی(md.DECISIONS_ENGINEERING( عالوه بر مسنند ،md.DESIGN هر تیم باید اایل دیگری با نام زیر ارائه کند: ENGINEERING_DECISIONS.md - هدف این مسنند، آشنایی تیم داوری با نتوه تتلیل مسئله و تصمیمهای مهندسی تیم است. حداکثر حجم این اایل **دو صفته** است. ---- -##ساخنار پیشنهادی -این مسنند باید حداقل به پرسشهای زیر پاسخ دهد. -۱. ###مهماری اننصابشده -مهماری کلی سیسنم چیست؟ -چرا این مهماری اننصاب شده است؟ -در صورت وجود گزینههای دیگر، چرا اننصاب نشدهاند؟ ---- -۲. ###مدلسازیWorkflow -Workflowچگونه مدل شده است؟ -اگر بانک مرحله جدیدی اضااه کند، چه بصشهایی از سیسنم تغییر خواهند کرد؟ --- -۳. ###قوانین کسبوکار -قوانین چگونه از اایل تنظیمات خوانده میشوند؟ -چرا این روش اننصاب شده است؟ ---- -۴. ###مدیریت وضهیت(Management State( -وضهیت اهلی درخواست چگونه مدیریت میشود؟ -چگونه از اجرای مجدد مراحل جلوگیری شده است؟ ---- -۵. ###ماندگاری اطالعات -چه مکانیزمی برای ذخیره اطالعات اننصاب شده است؟ -چرا این روش اننصاب شده است؟ ---- -۶. ###مهمترینoff-Trade ها -سه تصمیم مهم طراحی خود را توضی دهید. -برای هر تصمیم موارد زیر را بیان کنید. -گزینههای موجود -گزینه اننصابشده -دلیل اننصاب -مزایا -متدودیتها -۷. ###متدودیتهای اهلی -اگر زمان بیشنر داشنید، چه بصشهایی از سیسنم را بهیود میدادید؟ -۸. ###برنامه توسهه آینده -ارض کنید بانک درخواستهای زیر را مطرح کند. -اضااه شدن مرحلهAML -اضااه شدن مرحلهCheck Legal -اضااه شدن نوع جدیدی از تسهیالت --تغییر Workflow بانکها -توضی دهید مهماری اهلی چگونه از این تغییرات پشنییانی میکند. -#نکات -صراا شامل نمودارهای مهماری باشد. این مسنند نیاید -هدف این اایل، نمایش نتوه تفکر مهندسی تیم است. -کیفیت تتلیل و اسندتل از حجم مسنند مهمتر است. -. ۴۵مسننداسنراتژی و پوشش تستها(md.TESTING( -در این اایل تیم باید توضی دهد: -• چه تستهایی نوشنه است؟ -• چه بصشهایی را Test Unit کرده است؟ -• چه بصشهایی Test Integration شدهاند؟ -• چه بصشهایی را به دلیل متدودیت زمان تست نکرده است؟ -. ۴۶نکات پایانی -این چالش یک مسئله طراحی نرماازار است. -هیچ پاسخ واحد یا مهماری از پیش تهیینشدهای وجود ندارد. -از شرکتکنندگان اننظار میرود تصمیمهای مهندسی خود را مسنند کرده و در جلسه داوری از آنها دااع کنند. -۴۶. #ساخنار پروژه -ساخنار پروژه آزاد است و شرکتکنندگان میتوانند بر اساس زبان و مهماری اننصابی خود، ساخنار مناسیی طراحی کنند. حداقل اایلهای زیر باید در پروژه وجود داشنه باشند. +``` + +سرویس باید روی پورت `8080` در دسترس باشد و حداکثر ظرف ۶۰ ثانیه آماده پاسخ‌گویی شود. + +## ۲۵. اقلام قابل تحویل + +حداقل ساختار فایل‌های تحویلی باید به‌شکل زیر باشد: + +```text project/ -│ ├── src/ ├── Dockerfile ├── README.md ├── DESIGN.md ├── ENGINEERING_DECISIONS.md └── TESTING.md -در صورت نیاز میتوانید اایلهای دیگری نیز به پروژه اضااه کنید. -# ۴۷. Docker -پروژه باید با اسنفاده از Docker قابل اجرا باشد. -حداقل دسنورات زیر باید بدون نیاز به تغییر در پروژه اجرا شوند. ساختImage -```bash -docker build -t bankflow . -``` -اجرای پروژه -```bash -docker run -p 8080:8080 bankflow -``` -پروژه باید حداکثر ظرف ۶۰ ثانیه آماده پاسخگویی شود. --- -README.mdاایل# ۴۸. -READMEمهمترین راهنمای داور برای اجرای پروژه است. حداقل اطالعات زیر باید در آن وجود داشنه باشد. -##مهرای پروژه -توضی کوتاهی درباره راهکار ارائه شده. ---- -##پیشنیازها -در صورت وجود وابسنگی خاص توضی داده شود. --- -## Build -روش Build پروژه. ---- -## Run -روش اجرای پروژه. ---- -##اجرای تستها -توضی نتوه اجرای تستها. ---- -##ساخنار پروژه -مهرای پوشههای اصلی پروژه. ---- -##اناوریهای اسنفاده شده -اهرست زبان Database ،Framework ،و سایر اناوریهای اصلی. --- -DESIGN.mdاایل# ۴۹. -حداکثر سه صفته. -این اایل باید شامل موارد زیر باشد. -مهرای مهماری -اجزای اصلی سیسنم -نتوه اجرایWorkflow -نتوه توسههWorkflow -نتوه ذخیره اطالعات -نتوه مدیریت وضهیتها -نتوه جلوگیری از پردازش تکراری --مهمترین تصمیمهای طراحی ---- -ENGINEERING_DECISIONS.mdاایل# ۵۰. حداکثر دو صفته. -این اایل باید پاسصگوی پرسشهای زیر باشد. --چرا این مهماری اننصاب شده است؟ --چه گزینههای دیگری وجود داشت؟ --مهمترینoff-Trade های طراحی چیست؟ --اگر یک هفنه زمان بیشنر داشنید چه تغییراتی اعمال میکردید؟ -بزرگترین متدودیت راهکار اهلی چیست؟ ---- -TESTING.mdاایل# ۵۱. -حداکثر یک صفته. -در این اایل توضی دهید. --چه تستهایی نوشنه شده است؟ --چه بصشهایی Test Unit شدهاند؟ --چه بصشهایی Test Integration شدهاند؟ --چه بصشهایی به دلیل متدودیت زمان تست نشدهاند؟ ---- -۵۲. #متدودیتهای انی -شرکتکنندگان در اننصاب اناوری آزاد هسنند. -اسنفاده از موارد زیر اخنیاری است. -- Java -- Kotlin -- C# -- Go -- Rust -- Python -- Node.js -- PHP -- C++ - همچنین اسنفاده از Database ،ORM ،Framework و سایر ابزارها آزاد است. --- - ۵۳.موارد خارج از دامنه - پیادهسازی موارد زیر الزامی نیست. - -رابط کاربری(Frontend( -- Authentication -- Authorization -- Message Broker -- Kafka -- RabbitMQ -- Redis -- Kubernetes -- Cloud Deployment -- CI/CD -- Distributed Transaction -- Notification -- Core Banking Integration - -سیسنم واقهیReview Manual - اسنفاده از این اناوریها امنیاز مسنقیمی ایجاد نصواهد کرد. - ۵۴.متدودیتهای اجرایی - -پروژه باید تنها با اسنفاده از Docker اجرا شود. - -سروی باید روی پورت 8080 در دسنرس باشد. - -تمامAPI ها باید JSON باشند. - -زمان آماده شدن سروی نیاید بیش از ۶۰ ثانیه باشد. - Timestamp -ها باید مطابق اسناندارد UTC -8601ISO باشند. - ۵۵.آنچه در این چالش اهمیت دارد - این چالش یک مسئله طراحی نرماازار است. - موارد زیر بیشنرین اهمیت را دارند. - درسنی عملکرد سیسنم - طراحی مناسب - توسههپذیری - خوانایی کد - قابلیت نگهداری - قابلیت تست - سادگی طراحی - -مسنندسازی مناسب - پیچیدگی بیشنر، امنیاز بیشنر به همراه نصواهد داشت. ---- -۵۶. #پرسشهای منداول(FAQ( -##آیا اسنفاده از هوش مصنوعی مجاز است؟ -بله. -اسنفاده از ابزارهای هوش مصنوعی مجاز است. -با این حال، تیم باید بنواند در جلسه داوری از طراحی و پیادهسازی خود دااع کند. --- -##آیا اسنفاده از Microservice امنیاز دارد؟ -خیر. -امنیاز بر اساس کیفیت طراحی داده میشود، نه نوع مهماری. --- -##آیا اسنفاده از Kafka یا RabbitMQ امنیاز دارد؟ -خیر. -در صورت اسنفاده، تیم باید دلیل انی این اننصاب را توضی دهد. ---- -##آیا اسنفاده از Framework خاص امنیاز دارد؟ -خیر. -کامال آزاد است. اننصاب اناوری ---- -##آیا اسنفاده از SQLite مجاز است؟ -بله. -هر مکانیزم ذخیرهسازی که نیازمندیهای مسئله را برآورده کند، قابل قیول است. --- -##آیا اسنفاده از اایل به جای پایگاه داده مجاز است؟ -بله. -در صورتی که تمام نیازمندیهای Persistence رعایت شود. --- -##آیا ظاهر پروژه در امنیاز تأثیر دارد؟ -خیر. -رابط کاربری بصشی از این چالش نیست. ---- -##آیا اسنفاده از کنابصانههای مننباز مجاز است؟ -بله. -اسنفاده از کنابصانههای مننباز مجاز است. ---- -##آیا تزم است همه قابلیتها پیادهسازی شوند؟ -توصیه میشود ابندا تمام نیازمندیهای اصلی بهصورت صتی پیادهسازی شوند. پیادهسازی ناق قابلیتهای اصلی با اازودن قابلیتهای جانیی جیران نصواهد شد. -۵۷.جمعبندی -هدف این چالش، طراحی سامانهای است که عالوه بر عملکرد صتی ، از نظر کیفیت مهندسی نیز قابل دااع باشد. راهکار ارائه شده باید نشان دهد تیم توانسنه است: --مسئله را بهدرسنی تتلیل کند. --مهماری مناسیی اننصاب کند. --مسئولیتها را بهدرسنی تفکیک کند. --کدی خوانا و قابل توسهه تولید کند. --تصمیمهای مهندسی خود را مسنند و قابل دااع ارائه دهد. -مواق باشید. -اقالم تتویلی باید به این شکل باشد: -هدف فایل -Source Code پیادهسازی -اجرای پروژه Dockerfile -راهنمای اجرا md.README -مهرای مهماری md.DESIGN -تتلیل و تصمیمهای مهندسی md.DECISIONS_ENGINEERING -اسنراتژی و پوشش تستها md.TESTING +``` + +در صورت نیاز می‌توانید فایل‌های تکمیلی دیگری نیز اضافه کنید. + +### README.md + +این فایل مهم‌ترین راهنمای داور برای اجرای پروژه است و باید شامل موارد زیر باشد: + +- معرفی کوتاه راهکار؛ +- پیش‌نیازها و وابستگی‌های اصلی؛ +- روش Build؛ +- روش اجرا؛ +- روش اجرای تست‌ها؛ +- معرفی کوتاه ساختار پروژه؛ +- فهرست فناوری‌های اصلی. + +### DESIGN.md + +این فایل حداکثر سه صفحه است و باید حداقل موارد زیر را پوشش دهد: + +1. معماری و اجزای اصلی سیستم؛ +2. نحوه مدل‌سازی و اجرای Workflow؛ +3. نحوه انتخاب مرحله بعد؛ +4. تغییرات لازم برای افزودن یک Stage جدید؛ +5. نحوه خواندن قوانین کسب‌وکار از فایل تنظیمات؛ +6. نحوه ذخیره اطلاعات و مدیریت وضعیت‌ها؛ +7. نحوه جلوگیری از پردازش تکراری؛ +8. تغییرات لازم برای افزودن مرحله‌ای مانند `AML_CHECK`؛ +9. مهم‌ترین تصمیم‌ها و Trade-offهای طراحی. + +### ENGINEERING_DECISIONS.md + +این فایل حداکثر دو صفحه است و باید حداقل به پرسش‌های زیر پاسخ دهد: + +1. معماری کلی سیستم چیست و چرا انتخاب شده است؟ +2. چه گزینه‌های دیگری وجود داشت و چرا انتخاب نشدند؟ +3. Workflow چگونه مدل شده و افزودن یک مرحله چه بخش‌هایی را تغییر می‌دهد؟ +4. قوانین کسب‌وکار چگونه از فایل تنظیمات خوانده می‌شوند؟ +5. وضعیت فعلی چگونه مدیریت و از اجرای مجدد مراحل جلوگیری می‌شود؟ +6. چه مکانیزمی برای ماندگاری اطلاعات انتخاب شده و چرا؟ +7. سه تصمیم یا Trade-off مهم طراحی چه بوده‌اند؟ +8. محدودیت اصلی راهکار چیست؟ +9. اگر یک هفته زمان بیشتر داشتید، چه بخش‌هایی را بهبود می‌دادید؟ +10. معماری فعلی چگونه از توسعه‌های آینده پشتیبانی می‌کند؟ + +برای هر تصمیم مهم، گزینه‌های موجود، گزینه انتخاب‌شده، دلیل انتخاب، مزایا و محدودیت‌ها را بیان کنید. هدف این سند نمایش نحوه تفکر و استدلال مهندسی تیم است، نه صرفاً ارائه نمودارهای معماری. + +### TESTING.md + +این فایل حداکثر یک صفحه است و باید توضیح دهد: + +- چه تست‌هایی نوشته شده‌اند؛ +- چه بخش‌هایی Unit Test شده‌اند؛ +- چه بخش‌هایی Integration Test شده‌اند؛ +- چه بخش‌هایی به‌دلیل محدودیت زمان تست نشده‌اند. + +## ۲۶. نکات پایانی + +این چالش بیش از آنکه یک مسئله الگوریتمی باشد، یک مسئله مهندسی نرم‌افزار است و راه‌حل یا معماری واحدی ندارد. + +شرکت‌کنندگان باید با تحلیل مسئله، مناسب‌ترین طراحی را انتخاب کنند، تصمیم‌های مهندسی خود را مستند سازند و بتوانند در جلسه داوری از آن‌ها دفاع کنند. معیار ارزیابی، کیفیت راهکار است، نه پیچیدگی فناوری‌های استفاده‌شده.