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

۲۲.قابلیت توسهه
در طراحی سیسنم ارض کنید در آینده بانک اعالم کند:
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 باید پردازش درخواست را از مرحله اهلی آغاز کند.
پردازش تا رسیدن به یکی از وضهیتهای زیر ادامه پیدا میکند.
APPROVED
REJECTED
MANUAL_REVIEW
## Response
http
200 OK
json
{
"loanId":"L-10001",
"status":"APPROVED",
"currentStage":null
}
اگر وضهیت برابر REVIEW_MANUALًباشد
json
{
"loanId":"L-10001",
"status":"MANUAL_REVIEW",
"currentStage":null
}
اگر شناسه وجود نداشنه باشد
http
404 Not Found
json
{
"error":"LOAN_NOT_FOUND"
}
۳۲.رانار اجرای مجددProcess
قیال APPROVED یا REJECTED یاًREVIEW_MANUALًشده باشد، اجرای مجدد اگر درخواست process/ POST نیاید باعث اجرای دوباره Workflow شود. پاسخ باید وضهیت اهلی را برگرداند.
۳۳.دریاات اطالعات درخواست
## Endpoint
http
GET /api/v1/loans/{loanId}
## Response
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"
}
اگر شناسه وجود نداشنه باشد
http
404
json
{
"error":"LOAN_NOT_FOUND"
}
۳۴.دریاات تاریصچه پردازش
## Endpoint
http
GET /api/v1/loans/{loanId}/history
--- 
## Response
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 اقط یک بار ثیت میشود.
۳۵. Health Check
## Endpoint
http
GET /health
## Response
http
200 OK
json
{
"status":"UP"
}
۳۶.ارمت زمان
تمامTimestamp ها باید مطابق اسناندارد زیر باشند.
ISO-8601 UTC
نمونه
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
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 شدهاند؟
• چه بصشهایی را به دلیل متدودیت زمان تست نکرده است؟
. ۴۶نکات پایانی
این چالش یک مسئله طراحی نرماازار است.
هیچ پاسخ واحد یا مهماری از پیش تهیینشدهای وجود ندارد.
از شرکتکنندگان اننظار میرود تصمیمهای مهندسی خود را مسنند کرده و در جلسه داوری از آنها دااع کنند.
۴۶. #ساخنار پروژه
ساخنار پروژه آزاد است و شرکتکنندگان میتوانند بر اساس زبان و مهماری اننصابی خود، ساخنار مناسیی طراحی کنند. حداقل اایلهای زیر باید در پروژه وجود داشنه باشند.
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