معرفی کوتاه الگوی طراحی State/Status Segregation Pattern

💡چرا مدل‌سازی سیستم‌ها گره می‌خورد؟ شفاف سازی Lifecycle در مقابل Context به منظور مدلسازی بهتر سیستم

تا حالا توی مکالمات کاری، مخصوصاً با مدیر محصول، به جمله‌هایی مثل این برخوردین؟

سفارش هنوز فعاله، ولی پیک تو ترافیکه، رستوران هم هنوز تأیید نکرده. تازه، کاربر زنگ زده بود آدرس رو عوض کنه."

یه جمله‌ی ساده، ولی پر از اطلاعات:
🔵 «سفارش فعال است» → یه فاز اصلی از چرخه‌ی عمر
🟠 «پیک در ترافیکه، رستوران تأیید نکرده، تغییر آدرس» → شرایط موقت و همزمان.

اینجا همون جاییه که مدل‌سازی معمول ما (با یه enum تک‌بعدی، زمخت و پربار!) به مشکل می‌خوره:

enum OrderState {
  Placed,
  Preparing,
  RiderDelayed,
  RestaurantUnconfirmed,
  AddressChangeRequested,
  Delivered
}

این مدل به‌ظاهر ساده، مفاهیم غیرمرتبط رو با هم قاطی می‌کنه:
🔴 مقدار RiderDelayed یه وضعیت گذراست، نه فاز چرخه عمر
🔴 مقدار RestaurantUnconfirmed توی مرحله‌ی آماده‌سازی معنا داره، نه بعدش
🔴 مقدار AddressChangeRequested یه رخداد کاربره، نه حالت سفارش

📍 نتیجه؟‌ مدل به ظاهر ساده، ولی گول‌زننده، شکننده، مبهم و سخت تست‌پذیر!
———

راه‌حل غلبه بر چالش متداول بالا، تفکیک "State" و "Status"
برای حل این مسئله من الگوی State/Status Segregation Pattern یا به اختصار S3 رو معرفی کردم. S3 به بیان ساده:
یه اصل مدل‌سازی که به‌وضوح بین State (فاز انحصاری و پایدار چرخه عمر) و Status (شرایط موقت، خروجی و اکشن وابسته به آن State) تمایز قائل می‌شه.

🟡 در این مدل State (حالت) یعنی کجای فرآیندیم؟
کاملا Excusive هستند و چندین مقدار State با هم Mutually Excusive نیستند. اینها حالت پایدار هر موجودیت در طراحی رو مدل می‌کنند. مقادیرشون هم باعث تصمیم‌سازی در سیستم یا توسط کاربر می‌شود. (decision driver هستند). مثلا سفارشی که در وضعیت Draft است منتظر تسویه حساب شدن توسط کاربر میمونه.

enum OrderState { Draft, Paid, Issued, Cancelled }

• فقط یکی فعاله
• تعیین‌کننده‌ی منطق اصلی سیستم


🟠 و Status (وضعیت): چه اتفاقی افتاده؟ statusها مشخص کننده context یا outcome یک state هستند. همینطور observability سیستم رو توسط اینها مدل می‌کنیم. به ازای هر state ممکن است چندین status برای آن موجودیت وجود داشته باشد. بهمین خاطر exclusive نیستند. اینها بیشتر جنبه transient دارند.

enum OrderStatus {
  RiderDelayed,
  ConfirmationSMSSent,
  AddressChangeRequested
}

• می‌تونه چندتا باشه
• فقط توصیف شرایط لحظه‌ایه، نه کنترل روند اصلی

الگوی S3 چطور کار می‌کنه؟
این الگو با تاکید بر جداسازی این دو مفهوم در طراحی و مدلسازی سعی می‌کنه به مدلی برسه که شفاف، قابل تست و قابل گسترش است.

نمونه واقعی:

{
  "Order": {
    "State": "OutForDelivery",
    "Statuses": ["RiderDelayed", "AddressChangeRequested"]
  },
  "Settlement": {
    "PaymentStatus": "Settled",
    "LastAttempt": {
      "Status": "Success",
      "Time": "12:03"
    }
  }
}

🧠 الگوی S3 فقط یه روش نام‌گذاری نیست؛ یه زبان مشترک برای طراحی سیستمه.
این الگو بخشی از رویکرد مدل‌سازی و طراحی من در کتابی در دست نگارش با عنوان Language-Driven Design هست. الگوی S3 کمک می‌کنه مدل‌سازی‌مون شفاف، قابل تست و قابل گسترش بشه. با جدا کردن منطق چرخه عمر از وضعیت‌های contextی، هم ساختار کد تمیزتر می‌شه، هم APIها وضوح بیشتری پیدا می‌کنن. این الگو ما رو از enumهای زمخت، متورم، تک بعدی و درهم نجات می‌ده و کمک می‌کنه سیستم‌هایی بسازیم که هم قابل فهم‌ترن، هم راحت‌تر توسعه پیدا می‌کنن.

📎 لینک مقاله‌ 👇

https://masoudbahrami.medium.com/dont-confuse-state-with-status-when-modeling-domain-601bc91f326a


مکتب‌خانه DDD
@DomainDrivenDesign_ir