Venture Separation Architecture

1. مسئله‌ای که این درس مالک آن است

وقتی چند Venture از یک Platform استفاده می‌کنند، بحث معمولاً به دو شعار بد تقلیل پیدا می‌کند: «همه‌چیز را Share کنیم» یا «برای هر Venture همه‌چیز را جدا کنیم». هر دو Shortcut می‌توانند coupling، failure domain، data sensitivity، cadence و cost را پنهان کنند. ARC-001 فقط Venture Separation Architecture را مالک است؛ Repair/Canary در PLN-028 و Versioned Shared Interfaces در ARC-002 جدا می‌مانند.

2. خروجی قابل تحویل

خروجی شما Venture Boundary & Separation Decision Record v1 است. برای هر Capability باید Venture Scope، Tenancy Model، Isolation، Change Cadence، Data Sensitivity، Failure Domain، Owner، Shared/Marginal/Migration Cost، Coupling، Serviceability، Decision، Stop/Pivot Trigger و Evidence ثبت شود.

3. مدل ذهنی: Capability قبل از Venture-wide Architecture

تصمیم را capability-by-capability بگیرید: evidence → hard isolation gates → lifecycle/failure-domain gates → cost & coupling → proposed model comparison → bounded state. ممکن است Identity مشترک بماند، Customer Records به Bridge برسد و Audit Store کاملاً Silo شود. یک Architecture سالم مجبور نیست برای همه اجزا یک Model داشته باشد.

4. منابع بیرونی چه می‌گویند و چه نمی‌گویند

Azure Isolation را یک Spectrum می‌بیند و نشان می‌دهد انتخاب سطح Isolation روی security، cost، performance، reliability و tenant-specific responsiveness اثر دارد. AWS نیز Silo، Pool و Bridge را به‌عنوان الگوهای dedicated، shared و mixed توضیح می‌دهد. هیچ‌کدام نمی‌گویند Venture شما دقیقاً کجا باید جدا شود؛ آن تصمیم Evidence و Governance محلی می‌خواهد.

5. Hard Gateها را قبل از Cost بررسی کنید

Data Sensitivity و Failure Domain را با Cost عوض نکنید. اگر Capability نیاز DEDICATED یا Data RESTRICTED دارد، low volume دلیل کافی برای Shared کردن نیست. برعکس، برای Capability کم‌ریسک، جداکردن صرفاً به‌خاطر سلیقه می‌تواند Fleet Cost و Operational Load را بالا ببرد.

6. Lifecycle Cadence یک Boundary واقعی است

دو Venture ممکن است امروز Feature یکسان داشته باشند ولی cadence آن‌ها جدا شود. اگر یکی روزانه و دیگری ماهانه Release می‌دهد، shared deployment می‌تواند coupling را افزایش دهد. در این حالت Bridge می‌تواند منطقی باشد: بخش‌هایی مشترک، بخش‌هایی با lifecycle مستقل. Cadence change باید Record را reopen کند.

7. Cost را با Coupling و Migration با هم بخوانید

Shared Cost پایین به‌تنهایی «Share» را ثابت نمی‌کند و Dedicated Cost پایین نیز «Split» را ثابت نمی‌کند. Migration Cost، Coupling و ongoing shared/marginal cost باید هم‌زمان دیده شوند. در این Lab، افزایش مادی Shared Cost فقط وقتی Pivot ایجاد می‌کند که migration و coupling نیز recompute شده باشند.

8. Baseline کارشده: یک معماری Mixed

Baseline سه Capability دارد. identity-edge کم‌حساسیت و دارای Failure Domain مشترک است و SHARED می‌ماند. customer-records حساسیت بالا و Logical/Partitioned isolation دارد و BRIDGE است. regulated-audit نیاز Dedicated و داده Restricted دارد و SILO می‌شود. نتیجه ACCEPTED_MIXED است؛ نه «همه shared» و نه «همه silo».

9. Mutation اول: Isolation سخت‌تر بدون تغییر Traffic

اگر نیاز customer-records از HIGH/LOGICAL به RESTRICTED/DEDICATED برسد ولی تیم هنوز BRIDGE را نگه دارد، Decision باید PIVOT_REQUIRED شود. Traffic پایین یا بدون تغییر این Gate را خنثی نمی‌کند؛ Isolation Requirement عوض شده است.

10. Mutation دوم: Shared Platform Cost دو برابر می‌شود

اگر Operational Shared Cost یک Capability کم‌coupling به‌طور مادی افزایش یابد، Record باید cost/coupling/migration را دوباره حساب کند. در Fixture مربوط، identity-edge دیگر با مدل قبلی دفاع‌پذیر نیست و recommendation به SILO تغییر می‌کند. Verdict قبلی را Copy نمی‌کنیم.

11. Evidence ناقص یا متعارض Success نیست

اگر Evidence supporting failure domain حذف شود، UNKNOWN می‌گیریم؛ اگر evidence قدیمی باشد STALE و اگر دو Owner درباره Requirement متعارض باشند DISPUTED. این Stateها «مشکل نرم» نیستند؛ جلوی معماری قطعی را می‌گیرند تا Evidence repair شود.

12. Stop/Pivot Trigger بخشی از تصمیم است

هر Decision پذیرفته‌شده باید trigger داشته باشد: isolation requirement changes، shared cost materially shifts، cadence diverges، failure domain changes یا serviceability drops. Boundary بدون trigger به‌مرور به assumption پنهان تبدیل می‌شود.

13. Transfer: Venture چهارم با Isolation سخت و Volume پایین

در Transfer، Venture D Volume کمی دارد اما برای Customer Records Isolation سخت‌تری می‌خواهد. Record از نو ساخته می‌شود؛ Identity می‌تواند Shared بماند، اما Customer Records از Bridge به Silo می‌رود. Low volume دلیل حذف requirement نیست. نتیجه هنوز Mixed است، ولی decision vector آن با Baseline فرق می‌کند.

14. Lab و روش اجرا

به lab/ARC-001-LAB1/learner/ بروید و python run_checks.py را Offline اجرا کنید. هشت Fixture شامل Baseline، Isolation Raise، Shared-Cost Double، Cadence Divergence، Missing Evidence، Stale Evidence، Authority Conflict و Fourth-Venture Transfer است. هدف حفظ یک Verdict نیست؛ باید اولین Gate کنترل‌کننده و recomputation را توضیح دهید.

15. ارزیابی، Freshness و مرز ادعا

ارزیابی روی Boundary، Baseline Record، Negative Evidence و Transfer است. Azure/AWS فقط FACTهای isolation spectrum و silo/pool/bridge را محدود می‌کنند. Threshold هزینه، typed states، stop/pivot policy و Evidence Contract طراحی MAKNOW هستند. هیچ Live Split، Billing Change یا Tenant Migration در این درس انجام نمی‌شود و Canonical package فقط با Version جدید قابل تغییر است.