معماری فنی فعلی

MoboCore یک Connector ساده نیست؛ یک قرارداد عملیاتی بین Source، Portal و WooCommerce است

Portal وضعیت مرجع و عملیات شبکه را نگه می‌دارد؛ Mobo Core داخل Store تغییرات را با Queue و WooCommerce API اعمال می‌کند؛ Source Provider منبع کالا، موجودی و در صورت پشتیبانی، سفارش و کیف پول است.

سه لایه اصلی

مسئولیت هر بخش مشخص است

Source Provider

Product، Variant، Price، Stock، Media، Address/Shipping و قرارداد Order/Wallet در صورت پشتیبانی.

Portal (.NET)

License، Desired State، Webhook orchestration، Reconciliation، Site Health، Worker Routing و Remote Deployment.

Mobo Core (WordPress)

اعمال WooCommerce state، Queue/Retry، Media، Checkout validation، Order submission، Cache، Cron و Health report.

MoboCore technical architecture
Source، Portal، Workerها و Storeها در یک قرارداد مشخص ولی با مسئولیت‌های جدا قرار می‌گیرند.
Product / Variant

Event سریع است؛ Desired State مرجع نهایی

  1. Source تغییر را در Portal ثبت می‌کند.
  2. Portal Notification سبک با EventId/SyncId/ChangesUrl ارسال می‌کند.
  3. Mobo Core Event را در Event Store دیتابیسی Queue می‌کند؛ JSON fallback برای شرایط اضطراری دارد.
  4. Payload کامل در صورت نیاز Pull می‌شود.
  5. Product/Attribute/Variation با identity و signature اعمال می‌شوند؛ حذف‌های authoritative نیز پردازش می‌شوند.
  6. Heartbeat و Reconciliation Drift یا Event جاافتاده را دوباره کشف می‌کنند.
Desired state synchronization and recovery
Product/Variant changes با Event/Pull اعمال می‌شوند و Reconciliation اختلاف باقی‌مانده را برمی‌گرداند.
Media

تصویر از Product Sync جدا و غیرمسدودکننده است

  • ProductUpdated منتظر دانلود/Resize تصویر نمی‌ماند؛ کار Media وارد Queue جدا می‌شود.
  • Standard Media و Shared Media دو Mode مستقل هستند.
  • Image Queue وضعیت Pending/Due/Failed دارد و Retry کنترل‌شده انجام می‌شود.
  • نوسازی WebP و حذف فایل قدیمی فقط با Safety Check انجام می‌شود.
  • صف تصویر و Circuit Breaker در Health قابل مشاهده‌اند.
Site health and runtime observability
Image Queue در کنار Cron، Cache، Sync Health و Runtime diagnostics دیده می‌شود.
Checkout / Order

Checkout دست WooCommerce می‌ماند

  1. مشتری فقط روش‌های ارسال تعریف‌شده در WooCommerce را می‌بیند.
  2. Shipping Method انتخابی Store به شناسه Source نگاشت می‌شود؛ افزونه Rate موبو برای مشتری تولید نمی‌کند.
  3. Order Scope به Non-Mobo، All-Mobo یا Mixed تقسیم می‌شود.
  4. در Mixed Order فقط آیتم‌های موبویی برای Source آماده می‌شوند.
  5. Address Mapping و Shipping Mapping قبل از Submit بررسی می‌شوند.
  6. ثبت سفارش به‌صورت Queue و قابل Retry انجام می‌شود؛ Auto-complete فقط با Policy مربوط و برای سفارش تماماً موبویی معنا دارد.
WooCommerce checkout and source shipping mapping
Checkout محلی می‌ماند؛ Shipping Mapping فقط در Source Order Submission مصرف می‌شود.
Runtime

Real Cron، Self Runner و Lock lease

Queueها در دورهای منصفانه تا بودجه امن PHP تخلیه می‌شوند. Lock سراسری Token-based lease دارد و با Heartbeat تمدید می‌شود؛ Process دوم با وضعیت Locked خارج می‌شود و Crash باعث Lock دائمی نمی‌شود.

Multi-round

Webhook، Images، Product Sync، Reprice، Recategorize و Orders در یک اجرای طولانی‌تر سهم منصفانه می‌گیرند.

Targeted Cache

Product/Archive cache هدفمند invalidate می‌شود و فقط permalink همان Product برای Warmup صف می‌شود.

Health Telemetry

Cron Runner، Cache Purge، Portal Heartbeat، Sync Health و Upgrade Barrier به Portal گزارش می‌شوند.

Revenue

سود تاریخی از قیمت فعلی محصول محاسبه نمی‌شود

در Mobo Core 10.33.18، Source Cost روی Order Item Snapshot می‌شود و برای سفارش موفق Mobo پس از Completed شدن یک Ledger immutable ساخته می‌شود. Mixed Order فقط Lineهای موبویی را وارد محاسبه می‌کند. Portal Summary به‌صورت On-demand All Time، ۳۰ روز اخیر و ۱۰ محاسبه اخیر را می‌خواند.

Immutable revenue ledger
Source Cost در زمان سفارش Freeze می‌شود تا تغییر قیمت‌های آینده Profit تاریخی را بازنویسی نکند.
Repair

Repair ابزار Recovery است، نه مرحله اجباری هر نصب

نصب جدید یا Upgrade عادی به‌طور پیش‌فرض نیازمند «Repair کامل» نیست. Repair زمانی استفاده می‌شود که داده Legacy، Drift، مشکل identity یا Health/سناریوی مهاجرت نیاز به بازسازی گسترده‌تر را نشان دهد.