{
  "title": "ایجاد Core به عنوان Platform Control Plane",
  "slug": "team/platform/core/ADR/ADR-Core-002",
  "url": "/docs/team/platform/core/ADR/ADR-Core-002",
  "frontmatter": {
    "layout": "doc",
    "title": "ایجاد Core به عنوان Platform Control Plane",
    "description": "مستند تصمیم معماری — دلایل ایجاد لایه مستقل برای مدیریت دغدغه‌های پلتفرمی",
    "version": "1.0.0",
    "status": "APPROVED",
    "author": "xoxxel",
    "owner": "xoxxel",
    "created_at": "2026-06-11",
    "updated_at": "2026-06-13",
    "tags": "",
    "reviewers": ""
  },
  "sections": [
    {
      "level": 1,
      "heading": "ایجاد Core به عنوان Platform Control Plane",
      "content": "**Core as Platform Control Plane**\n\n> **ADR-Core-002**\n\n---"
    },
    {
      "level": 2,
      "heading": "وضعیت",
      "content": "**Status**\n\n✅ **تایید شده (APPROVED)**\n\n---"
    },
    {
      "level": 2,
      "heading": "تاریخ",
      "content": "**Date**\n\n2026-06-11\n\n---"
    },
    {
      "level": 2,
      "heading": "زمینه",
      "content": "**Context**\n\nپروژه NONS بر پایه معماری رویدادمحور و مجموعه‌ای از سرویس‌های مستقل طراحی شده. با افزایش تعداد سرویس‌ها، نیازمندی‌هایی به وجود میاد که متعلق به هیچ دامنه کسب‌وکار (بیزنس) خاصی نیستن، بلکه در سطح کل پلتفرم مطرح هستن؛ مواردی مثل:\n\n- ثبت و رهگیری رویدادها\n- اعتبارسنجی فنی رویدادها\n- نظارت بر سلامت سرویس‌ها\n- مدیریت وضعیت سرویس‌ها\n- اعمال استانداردهای فنی مشترک\n\nقرار دادن این مسئولیت‌ها داخل سرویس‌های دامنه‌ای (مثل سفارش یا پرداخت) باعث تکرار منطق، افزایش وابستگی (Coupling) و عدم هماهنگی در سطح کل پلتفرم می‌شه. پس وجود یه لایه مستقل واسه مدیریت دغدغه‌های پلتفرمی کاملاً ضروری هستش.\n\n---"
    },
    {
      "level": 2,
      "heading": "تصمیم",
      "content": "**Decision**\n\nیه سرویس مستقل به اسم **Core** به عنوان Platform Control Plane رسمی پروژه NONS ایجاد می‌شه.\nCore یه سرویس زیرساختیه و بخشی از هیچ کدوم از دامنه‌های کسب‌وکاری نیست.\n\nوظیفه Core مدیریت کارهای فنی مشترک در سطح پلتفرم هست و سرویس‌های دیگه بدون وابستگی مستقیم به اون و صرفاً از طریق Event Bus (NATS) باهاش تعامل دارن.\n\nپیاده‌سازی Core بر اساس ADR-Platform-001 (لایه قراردادها) با زبان Go انجام می‌شه و از بایندینگ‌های Go تولیدشده در مسیر `nons-api/contracts/` برای اعتبارسنجی Envelope و Registry استفاده می‌کنه.\n\n> [!IMPORTANT]\n> **Core یه سرویسه، نه یه فریمورک یا کتابخانه مشترک. بقیه سرویس‌ها نباید هیچ وقت کدهای Core رو ایمپورت کنن.**\n\n---"
    },
    {
      "level": 2,
      "heading": "محدوده مسئولیت",
      "content": "**Scope of Responsibility**\n\nمسئولیت Core فقط به این موارد محدوده:\n\n- Audit Logging\n- Technical Event Validation\n- Service Registry\n- Health Monitoring\n- Platform Governance\n\nاین وظایف فقط در سطح فنی و زیرساختی تعریف می‌شن و هیچ منطق کسب‌وکاری (بیزنس لوگات) ندارن.\n\n---"
    },
    {
      "level": 2,
      "heading": "محدودیت‌ها",
      "content": "**Constraints**\n\nCore نباید هیچ مدل دامنه‌ای یا دانش کسب‌وکاری داشته باشه.\n\nنمونه‌هایی از کارهای ممنوعه توی Core:\n\n- احراز هویت و مجوزها (Authentication / Authorization)\n- مدیریت و پردازش پرداخت‌ها، کیف پول و تسویه حساب (Payment / Wallet / Settlement)\n- مدیریت سفارش‌ها و محصولات (Order / Product)\n- جستجو و سیستم چت (Search / Chat)\n- هماهنگی فرآیندها و گردش‌های کار (Workflow / Saga)\n\nبعضی مفاهیم بیزنسی که وجودشون توی کدهای Core نقض معماری به حساب میاد:\n\n- `OrderStatus`\n- `PaymentStatus`\n- `WalletTransaction`\n- `MarketplaceProduct`\n\n---"
    },
    {
      "level": 2,
      "heading": "پیامدها",
      "content": "**Consequences**"
    },
    {
      "level": 3,
      "heading": "مزایا",
      "content": "**Pros**\n\n- تفکیک کاملاً شفاف کارهای فنی و بیزنسی.\n- کاهش وابستگی (Coupling) بین سرویس‌ها.\n- استانداردسازی نظارت و ثبت رویدادها.\n- امکان توسعه و تغییر مستقل سرویس‌های دامنه‌ای.\n- افزایش پایداری معماری پلتفرم در بلندمدت.\n- امکان تغییر فناوری سرویس‌ها به صورت جداگانه."
    },
    {
      "level": 3,
      "heading": "معایب",
      "content": "**Cons**\n\n- اضافه شدن یه سرویس عملیاتی جدید به سیستم.\n- نیاز به نگهداری و پایش (Monitoring) مستقل.\n- تحمیل هزینه‌های نگهداری لایه پلتفرم (که مدیریت آن به طور رسمی با چارت‌های Helm در شاخه `deploy/` و استقرار بر روی کلاستر K3s/K3d ساده‌سازی می‌شود (D13, D14, D15))."
    }
  ]
}