Native Mobile, Custom Billing و SaaS Multi-tenancy Awareness

سه فناوری، سه مسئله، سه تصمیم مستقل

یک SaaS وب‌محور را تصور کنید که PWA responsive دارد، اشتراک‌هایش را با provider billing اداره می‌کند و چند مشتری سازمانی را در یک deployment مشترک سرویس می‌دهد. حالا roadmap یک بسته‌ی «بلوغ محصول» پیشنهاد می‌کند: اپ iOS/Android native، موتور Custom Billing، و زیرساخت جدا برای هر tenant. این بسته در ظاهر منسجم است، اما سه مسئله‌ی متفاوت را به یک تصمیم تبدیل می‌کند.

Native Mobile باید از یک gap واقعی در capability یا distribution شروع شود: آیا background work، Bluetooth، device API، offline behavior یا app-store distribution چیزی را حل می‌کند که web/PWA موجود نمی‌تواند؟ Custom Billing باید از gap واقعی در billing model و ownership شروع شود: آیا subscription/invoice state یا قرارداد تجاری موردنیاز با provider فعلی قابل بیان نیست؟ SaaS Multi-tenancy باید از requirement واقعی tenant/isolation/residency شروع شود: آیا مشتریان، مرز isolation، noisy-neighbor control یا regional residency می‌خواهند که shared deployment فعلی پاسخ نمی‌دهد؟

راهنمای معماری Android توصیه می‌کند boundaryهای UI/data روشن باشند و معماری با نیاز app تطبیق داده شود؛ این FACT نمی‌گوید هر محصول وبی باید native شود. [ANDROIDARCH] Stripe Billing lifecycle اشتراک و invoice state را مدل می‌کند؛ این FACT ضرورت ساخت billing engine اختصاصی را ثابت نمی‌کند. [STRIPEBILL] راهنمای Azure برای multitenancy مدل‌های مختلف tenancy/isolation و trade-offهای sharing، cost، reliability و customer requirement را توضیح می‌دهد؛ این FACT یک معماری tenancy واحد را برای همه‌ی SaaSها اجباری نمی‌کند. [AZTENANCY]

خروجی درس Native/Billing/Tenancy Adoption Decision Matrix v1 است. سه row مستقل دارد: NATIVE_MOBILE، CUSTOM_BILLING و SAAS_MULTI_TENANCY. stateهای مجاز: USE، PILOT، NOT_NOW، UNKNOWN، EVIDENCE_INCOMPLETE، OWNER_MISSING، REVIEW_REQUIRED، HOLD، PARTIAL و DISPUTED. نبود evidence تعیین‌کننده هرگز با «به‌هرحال در آینده لازم می‌شود» به USE یا PILOT تبدیل نمی‌شود.

زمان فعال برنامه‌ریزی‌شده: ۴۵ دقیقه.

این درس برای کسی است که باید قبل از adoption، problem-fit و lifecycle burden سه محور را مستقل و قابل ممیزی کند.

این درس app منتشر نمی‌کند، billing واقعی را جایگزین نمی‌کند، production tenant را جابه‌جا نمی‌کند و outcome درس‌های Microservices/Full Offline Studio یا Portfolio/Marketplace را جذب نمی‌کند.

پیش‌نیاز HARD — AWR-001

پیش از Fast Path، boundary مرتبط از AWR-001 را در یک جمله بنویسید: چرا «فناوری جدی/مدرن» به‌تنهایی trigger adoption نیست و چه evidenceای باید قبل از USE وجود داشته باشد؟ سپس یک non-goal از AWR-001 را نام ببرید که نباید وارد تصمیم Native/Billing/Tenancy شود. اگر نمی‌توانید problem، measured trigger، simpler alternative و owner/cost را به‌عنوان اجزای تصمیم از هم جدا کنید، Fast Path برای شما باز نیست.

پل محدود: فقط این evidence rule را بازیابی و ثبت کنید: «نام یا modernity یک technology دلیل adoption نیست؛ مسئله‌ی مشخص، trigger قابل‌اندازه‌گیری، simpler alternative، operational owner، burden و revisit trigger باید دیده شوند و NOT_NOW می‌تواند نتیجه‌ی درست باشد.» این bridge نتیجه‌ی Kubernetes/Kafka درس AWR-001 را تکمیل یا جعل نمی‌کند؛ فقط evidence slice لازم برای ورود به این درس را برمی‌گرداند.

قبل از انتخاب تکنولوژی، نوع gap را تشخیص دهید

چهار تشخیص کوتاه:

1. یک feature به camera نیاز دارد، اما background work، offline execution یا distribution requirement وجود ندارد. آیا همین یک feature Native Mobile را USE می‌کند؟
2. تیم pricing plan تازه‌ای می‌خواهد که provider فعلی از آن پشتیبانی می‌کند. آیا Custom Billing لازم است؟
3. یک SaaS پنج مشتری کوچک دارد و هیچ requirement صریح isolation/residency ندارد. آیا «enterprise شدن» به‌تنهایی tenancy architecture جدید را توجیه می‌کند؟
4. یک مشتری regulated، isolation قوی و regional residency می‌خواهد. آیا این evidence می‌تواند tenancy row را تغییر دهد بدون آن‌که Native و Billing را هم تغییر دهد؟

۴ از ۴ → Fast Path. ۲ تا ۳ → Repair Path. ۰ تا ۱ → Foundation Path. Fast Path تعریف‌های مقدماتی را کوتاه می‌کند، اما negative evidence، support burden، migration/rollback و transfer را حذف نمی‌کند.

خودسنجی: capability را requirement فرض نکنید؛ provider feature را provider gap ننامید؛ tenant count را isolation requirement فرض نکنید؛ و NOT_NOW را «شکست بلوغ» ندانید.

مدل ذهنی: سه زنجیره‌ی evidence، نه یک maturity ladder

NATIVE_MOBILE → product gap → native-only/device/distribution/offline requirement → simpler web/PWA option → owner + support/migration/rollback → bounded state

CUSTOM_BILLING → billing-model gap → provider capability gap → subscription/invoice/tax ownership → simpler provider configuration → owner + support/migration/rollback → bounded state

SAAS_MULTI_TENANCY → tenant definition/count → isolation/residency/noisy-neighbor requirement → simpler shared deployment option → owner + support/migration/rollback → bounded state

در هر محور ابتدا problem را از technology name جدا کنید. سپس trigger را اندازه‌گیری کنید. بعد alternative موجود را واقعاً بررسی کنید. در پایان lifecycle burden را وارد کنید. اگر trigger غایب است، NOT_NOW می‌تواند شواهدی و درست باشد. اگر trigger یا owner نامعلوم است، UNKNOWN، EVIDENCE_INCOMPLETE، OWNER_MISSING، REVIEW_REQUIRED، HOLD، PARTIAL یا DISPUTED را حفظ کنید؛ uncertainty را به success تبدیل نکنید.

سه لایه‌ی authority را جدا نگه دارید: FACT بیرونی mechanism/capability را توضیح می‌دهد؛ evidence محلی problem/trigger/constraint را ثبت می‌کند؛ DESIGN در MAKNOW state vocabulary و acceptance gate را تعیین می‌کند. اگر diagram رندر نشد، همین flow متنی جایگزین کامل asset://AWR-005/AWR-005-ASSET-FLOW است.

پایه‌ها: evidence contract هر محور

NATIVE_MOBILE

product_capability_gap را نام ببرید؛ سپس native_only_requirement، device_api_requirement، distribution_requirement و offline_requirement را جدا کنید. «camera وجود دارد» فقط capability need است؛ اگر web API/PWA همان workflow را با reliability موردنیاز پوشش دهد، native-only gap هنوز ثابت نشده است. operational_owner، support_burden، simpler_alternative، migration_cost و rollback_path باید صریح باشند. Android guidance درباره‌ی معماری app FACT است، adoption authority نیست. [ANDROIDARCH]

CUSTOM_BILLING

billing_model، subscription_state_owner، invoice_tax_requirement و provider_capability_gap را ثبت کنید. سؤال کلیدی «آیا billing پیچیده است؟» نیست؛ سؤال این است که کدام model/contract/state requirement با provider موجود قابل بیان نیست و مالک operational state بعد از custom شدن چه کسی است. Stripe Billing lifecycle و recurring primitives را توصیف می‌کند، اما ضرورت custom engine را ثابت نمی‌کند. [STRIPEBILL]

SAAS_MULTI_TENANCY

tenant_definition و tenant_count را با isolation_requirement، data_residency_requirement و noisy_neighbor_risk اشتباه نگیرید. تعداد tenant به‌تنهایی معماری isolation را تعیین نمی‌کند. Azure چند الگوی tenancy و trade-off را بیان می‌کند؛ انتخاب مدل باید به requirement واقعی، reliability/cost و operations وصل شود. [AZTENANCY]

برای هر سه row، evidence_ref، rationale، decision_state، review_due و stop_or_pivot_trigger لازم‌اند.

ساخت Native/Billing/Tenancy Adoption Decision Matrix v1

گام ۱: سه row بسازید و هیچ score مشترک «enterprise maturity» ندهید. یک row می‌تواند PILOT باشد، دیگری NOT_NOW و سومی REVIEW_REQUIRED.

گام ۲: برای Native، gap را از device capability به business workflow وصل کنید. اگر نیاز به Bluetooth background scanning، reliable background camera processing، offline capture/sync یا distribution policy دارید، evidence باید نشان دهد PWA موجود کجا کم می‌آورد. اگر فقط «تجربه بهتر» گفته می‌شود، trigger هنوز operational نشده است.

گام ۳: برای Billing، provider gap را با یک requirement مشخص ثابت کنید. usage-based contractual invoicing، state ownership، tax/invoice semantics یا reconciliation می‌تواند constraint باشد، اما اگر provider فعلی همان pricing model را پشتیبانی می‌کند، Custom Billing با همان evidence نباید success شود.

گام ۴: برای Tenancy، customer requirement را از architecture fashion جدا کنید. regulated isolation، residency، noisy-neighbor risk یا contractual separation باید قابل استناد باشد. shared deployment تا وقتی نیاز را برآورده می‌کند، simpler alternative معتبر است.

گام ۵: owner و burden را وارد کنید. Native یعنی حداقل دو client lifecycle، release/distribution و support surface. Custom Billing یعنی state correctness، reconciliation، invoice/tax ownership و migration risk. Multi-tenancy یعنی isolation controls، observability، placement، migration و incident boundary. قیمت واقعی اختراع نکنید؛ burden class و مسئولیت را ثبت کنید.

گام ۶: rollback را قبل از adoption تعریف کنید. native pilot بدون rollback به web flow، billing migration بدون route بازگشت به provider، یا tenancy split بدون reverse/migration path تصمیم bounded نیست.

گام ۷: state را از evidence نتیجه بگیرید. USE و PILOT success states هستند و فقط با trigger present + owner + lifecycle evidence مجازند. NOT_NOW فقط وقتی trigger به‌صورت measured absent است معتبر است. unknown decisive evidence باید uncertainty بماند.

مثال کامل: وب فعلی هنوز جواب می‌دهد

Baseline synthetic fixture: محصول PWA responsive دارد؛ camera فقط در foreground نیاز است، background/offline requirement ندارد و app-store distribution requirement ثبت نشده است. subscriptionهای standard monthly/annual با provider فعلی اجرا می‌شوند و pricing جدید هم در همان primitives قابل بیان است. پنج مشتری business در shared deployment هستند؛ isolation/residency contractual requirement ثبت نشده و noisy-neighbor incident اندازه‌گیری نشده است.

در Native row، product_capability_gap باید به این evidence وصل شود که web/PWA برای workflow فعلی کافی است. نتیجه‌ی worked example می‌تواند NOT_NOW باشد، چون trigger غایبِ اندازه‌گیری‌شده داریم، نه چون native «بد» است. در Billing row، provider capability gap ثبت نشده است؛ بنابراین custom engine نباید صرفاً برای ownership بیشتر success شود. در Tenancy row، tenant وجود دارد اما isolation/residency trigger غایب است؛ shared deployment alternative هنوز core requirement را پوشش می‌دهد.

این مثال oracle آزمایشگاه نیست. learner در lab://AWR-005/AWR-005-LAB1 final decision را خودش وارد می‌کند و checker فقط fixture binding و rule consistency را می‌سنجد. جدول canonical کار در asset://AWR-005/AWR-005-ASSET-TABLE قرار دارد و ۱۵ ستون آن problem، trigger، gap، tenant/isolation، alternative، owner، burden، migration، rollback، decision، review، stop/pivot trigger و evidence را کنار هم نگه می‌دارد.

مثال منفی نزدیک: «یک camera feature اضافه شده» اما background/offline/distribution requirement همچنان absent است. این mutation Native USE را توجیه نمی‌کند و باید field/state نامعتبر را تشخیص دهید.

failure modeها و repair کوچک

1. «هر SaaS جدی native app دارد.» مشکل: category prestige جای product gap نشسته است. Repair: دقیقاً یک workflow و یک native-only/device/distribution/offline requirement را نشان دهید.

1. «Billing برای ما مهم است، پس باید مالک stack باشیم.» مشکل: ownership preference جای provider gap است. Repair: یک billing model یا state/invoice constraint که provider فعلی نمی‌تواند پوشش دهد ثبت کنید؛ اگر provider پشتیبانی می‌کند، trigger absent است.

1. «مشتری سازمانی داریم، پس per-tenant infrastructure لازم است.» مشکل: customer label جای isolation/residency evidence است. Repair: requirement قراردادی یا measured noisy-neighbor/isolation risk را بیاورید.

1. owner حذف شده اما state هنوز USE است. این تصمیم fail می‌شود؛ capability بدون operational ownership success نیست.

1. migration cost یا rollback path خالی است. adoption ممکن است technically plausible باشد اما bounded و reversible نیست. state را تا تکمیل evidence پایین نگه دارید.

1. evidence تعیین‌کننده نامعلوم است اما NOT_NOW نوشته شده است. NOT_NOW به معنی measured absent trigger است، نه «نمی‌دانیم». در حالت unknown از UNKNOWN، EVIDENCE_INCOMPLETE، OWNER_MISSING، REVIEW_REQUIRED، HOLD، PARTIAL یا DISPUTED استفاده کنید.

Repair Path فقط dimension خراب را دوباره می‌سنجد؛ لازم نیست کل matrix را از نو بسازید.

برای فرد باتجربه: از preference به decision economics بروید

اگر با Android، billing یا tenancy آشنا هستید، تعریف ابزارها را کوتاه کنید و روی trade-off دفاع‌پذیر تمرکز کنید. برای Native از خود بپرسید: چه workflowای فقط با platform integration موردنظر feasible/reliable می‌شود و هزینه‌ی حفظ parity میان web و native چیست؟ برای Billing: کدام state transition یا قرارداد تجاری واقعاً از provider boundary بیرون است و reconciliation/tax/invoice ownership را چه تیمی می‌پذیرد؟ برای Tenancy: چه isolation/residency/SLO requirement در shared model شکسته می‌شود و blast radius کاهش‌یافته چه operational costی دارد؟

Experienced Path حق ندارد evidence bar را کم کند. حتی اگر technology fit intuitively روشن است، evidence_ref، owner، support burden، migration/rollback و review trigger باید visible بمانند. همچنین یک positive axis نباید دو axis دیگر را با خود بالا بکشد. یک regulated tenant ممکن است tenancy PILOT را توجیه کند، در حالی که Native همچنان NOT_NOW و Billing همچنان provider-hosted بماند. بالعکس، Bluetooth background requirement می‌تواند Native را تغییر دهد بدون آن‌که isolation یا billing gap ایجاد کند.

trade-offها: ساده‌ترین گزینه‌ای که evidence را پوشش می‌دهد

برای Native، alternative می‌تواند responsive PWA، Web APIs، installable PWA یا یک thin native wrapper/pilot باشد. سؤال «کدام شیک‌تر است؟» نیست؛ سؤال این است که کدام گزینه measured capability gap را با کمترین duplicated client lifecycle و support burden پوشش می‌دهد.

برای Billing، alternative معمولاً configuration/provider primitives، hosted checkout/subscriptions یا محدودکردن model به semantics پشتیبانی‌شده است. اگر requirement اقتصادی را provider پوشش می‌دهد، ساخت engine اختصاصی complexity جدیدی برای state correctness و reconciliation ایجاد می‌کند.

برای Tenancy، alternative می‌تواند shared deployment با logical isolation، targeted data boundary، noisy-neighbor controls یا فقط isolation برای tenantهای regulated باشد. راهنمای Azure خودِ trade-off میان sharing، cost، reliability و customer requirement را برجسته می‌کند. [AZTENANCY]

PILOT زمانی مفید است که trigger present ولی uncertainty کنترل‌پذیر باشد و pilot دارای owner، scope، stop trigger و rollback باشد. USE به evidence قوی‌تر برای sustained need و lifecycle ownership نیاز دارد. NOT_NOW زمانی درست است که trigger measurable absent باشد و alternative فعلی core need را پوشش دهد.

تمرین هدایت‌شده و مستقل

تمرین هدایت‌شده: fixture camera-only را باز کنید. فقط Native row را تحلیل کنید. آیا camera requirement به background/offline/distribution need تبدیل شده است؟ اگر نه، success state را رد کنید و یک review trigger بنویسید که در چه تغییر measurableای باید تصمیم باز شود. سپس billing و tenancy rowها را دست‌نخورده از evidence خودشان recompute کنید.

تمرین دوم: pricing model تازه‌ای اضافه شده اما provider فعلی آن را پشتیبانی می‌کند. field provider_capability_gap را بررسی کنید. Custom Billing success تا وقتی gap absent است نباید عبور کند.

تمرین سوم: یک tenant regulated با strong isolation و regional residency اضافه می‌شود. فقط Tenancy row باید به‌خاطر این evidence باز شود. آیا owner، migration cost و rollback path کافی‌اند؟ اگر نیستند، trigger present است اما success هنوز ممکن است OWNER_MISSING یا REVIEW_REQUIRED باشد، نه NOT_NOW.

تمرین مستقل/transfer: محصول دوم Bluetooth/camera background-work، usage-based contractual invoicing خارج از provider capability و یک regulated enterprise tenant با isolation/residency قوی دارد. هر سه row را از صفر بسازید. baseline decision را کپی نکنید.

resource ثابت: lab://AWR-005/AWR-005-LAB1.

verification: تصمیم باید از evidence قابل بازتولید باشد

Reviewer باید بتواند بدون hidden reasoning هر row را بازسازی کند. حداقل checks:

• fixture evidence دقیقاً به shipped fixture انتخاب‌شده bind شده باشد؛
• authority_refs هر row، FACT محور را به source رسمی خودش و decision gate را به DESIGN این درس trace کند؛
• سه axis مستقل باشند؛
• success state فقط با trigger present و owner/lifecycle evidence عبور کند؛
• Native success بدون native-only/device/distribution/offline gap رد شود؛
• Custom Billing success بدون provider capability gap رد شود؛
• Tenancy success بدون isolation/residency/noisy-neighbor trigger رد شود؛
• missing owner success را رد کند؛
• missing decisive evidence به success یا NOT_NOW coerced نشود؛
• rationale، review_due و stop_or_pivot_trigger خالی نباشند؛
• migration/rollback برای success states مشخص باشد.

AI می‌تواند fixture را سازمان دهد و consistency check اجرا کند، اما نمی‌تواند trigger، owner، provider gap، tenant requirement یا production approval اختراع کند. Human reviewer مسئول bounded decision است.

Evidence artifact را به‌صورت سه record کامل نگه دارید و در assessment کاربردی به آن reference دهید.

ارزیابی و transfer

AWR-005-F1: boundary متعلق به این درس و یک non-goal مجاور را توضیح دهید.

AWR-005-F2: mutation «یک camera feature بدون background/offline/distribution requirement» را تشخیص دهید؛ field/state نامعتبر و کوچک‌ترین repair را بنویسید.

AWR-005-F3: transfer را با evidence جدید recompute کنید.

AWR-005-S1 — retrieval: چرا Native، Billing و Tenancy سه decision جدا هستند و یک non-goal چیست؟

AWR-005-S2 — application: از baseline fixture، Native/Billing/Tenancy Adoption Decision Matrix v1 کامل بسازید.

AWR-005-S3 — diagnosis: camera-only mutation را تحلیل کنید و consequence + minimal repair را نشان دهید.

AWR-005-S4 — transfer: محصول دوم Bluetooth/camera background work، usage-based contractual invoicing و regulated isolation/residency دارد. سه state را مستقل recompute کنید و برای هرکدام owner، alternative، migration/rollback و review trigger را دفاع کنید.

تمام S1 تا S4 blocking هستند. Answer key در learner package وجود ندارد؛ reviewer evidence quality و boundedness را می‌سنجد.

منابع، freshness و مرز ادعا

[ANDROIDARCH] Android Developers — Architecture recommendations. در این درس فقط برای FACT مربوط به boundaryهای معماری app و adapt کردن recommendation به نیاز app استفاده می‌شود؛ این منبع adoption native را برای هر web product ثابت نمی‌کند.

[STRIPEBILL] Stripe Documentation — Billing subscriptions overview. برای FACT مربوط به subscription lifecycle و recurring billing state استفاده می‌شود؛ ضرورت Custom Billing از آن استنتاج نمی‌شود.

[AZTENANCY] Microsoft Azure Architecture Center — Multitenant tenancy models. برای FACT مربوط به مدل‌های tenancy/isolation و trade-off sharing/cost/reliability/customer requirement استفاده می‌شود؛ یک tenancy architecture واحد را تحمیل نمی‌کند.

هر سه منبع در 2026-09-03 بازیابی شده‌اند و بازبینی بعدی آن‌ها برای 2026-12-02 برنامه‌ریزی شده است. دامنه‌ی استفاده از هر منبع فقط همان FACTهای توضیح‌داده‌شده در بالا است؛ اگر semantics پلتفرم پیش از این تاریخ به‌طور معنادار تغییر کند، همان FACTها را زودتر دوباره بررسی کنید.

Synthetic fixtures اثبات رفتار production، هزینه‌ی واقعی، tax/legal treatment یا customer contract نیستند. هیچ app، billing account، cloud tenant یا production data در این درس mutate نمی‌شود.