معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۳ — Cost، Pricing، P&L، Entitlement و SLA · 241
Anti-fork Customization
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «Anti-fork Customization». می‌تواند برای «Anti-fork Customization» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خلاصهٔ درس
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «Anti-fork Customization».
می‌تواند برای «Anti-fork Customization» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خروجی این درس
می‌تواند برای «Anti-fork Customization» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
1) مسئله‌ای که این درس حل می‌کند
یک درخواست مشتری ممکن است در روز اول با یک branch اختصاصی «سریع» به‌نظر برسد، اما همان branch می‌تواند بعداً مسیر upgrade، patch امنیتی، QA و support را از محصول مشترک جدا کند. هدف این درس تصمیم‌گیری دربارهٔ سطح variation است، نه انجام تغییر زنده.
2) مرز درس و خروجی قابل تحویل
خروجی این درس Anti-fork Customization Decision Contract v1 است. این درس مالک SLA/Support درس ARC-021 یا معماری اطلاعات سایت COM-001 نیست و هیچ fork، migration یا mutation واقعی ایجاد نمی‌کند.
3) Fact: یک codebase می‌تواند چند deploy داشته باشد
Twelve-Factor اصل «one codebase, many deploys» را بیان می‌کند. نسخه‌های فعال deployها ممکن است متفاوت باشند، اما آن‌ها یک codebase مشترک دارند. این FACT یک boundary pattern است؛ به‌تنهایی سیاست تجاری MAKNOW دربارهٔ fork را تعیین نمی‌کند.
4) Fact: config متغیر بین deploy را از code جدا کن
Twelve-Factor config را چیزی می‌داند که بین deployها تغییر می‌کند و جداسازی آن از code را توصیه می‌کند. بنابراین یک مقدار deploy-specific لزوماً نیازمند source patch نیست؛ اما هر config دلخواه هم سالم نیست—schema، owner و test همچنان لازم‌اند.
5) Fact: base و overlay در Kustomize
Kubernetes Kustomize مفهوم base و overlay را دارد؛ base از overlay اطلاعی ندارد و می‌تواند در چند overlay reuse شود. این الگو نشان می‌دهد variation می‌تواند روی یک base مشترک سوار شود، ولی sustainable بودن customization تجاری را خودکار ثابت نمی‌کند.
6) Extension contract با internal hook فرق دارد
یک extension عمومی و versioned، contract مشخص دارد؛ اتصال plugin به internal API بدون version contract فقط coupling پنهان است. Kubernetes Custom Resources/Controllers نیز نمونه‌ای از extension API declarative هستند، نه مجوزی برای وابستگی به هر internal detail.
7) هشت مسیر تصمیم را از هم جدا کن
هر request باید ابتدا در یکی از مسیرهای bounded config، entitlement، declarative overlay، public extension، upstream product change، companion service، explicit fork exception یا decline/hold قرار گیرد. «customer-specific» بودن به‌تنهایی variation type نیست.
8) Canonical Core را منبع حقیقت نگه دار
canonical_core_ref باید برای همهٔ deployها قابل اشاره باشد. اگر source patch مشتری عملاً به منبع حقیقت جدید تبدیل شود، anti-fork بودن از بین رفته حتی اگر نام branch هنوز «temporary» باشد.
9) Compatibility و Upgrade evidence مستقل‌اند
compatibility_window فقط ادعا نیست؛ باید با upgrade_test_ref به target core/extension version متصل شود. موفقیت روی baseline قدیمی نمی‌تواند compatibility release بعد را اثبات کند.
10) Security patch path یک gate بحرانی است
اگر fix امنیتی فوری روی canonical core قابل انتشار باشد ولی customer fork آن را merge نکند، آن customization یک debt معمولی نیست؛ مسیر patch شکسته است. state باید BLOCKED بماند تا evidence اصلاح شود.
11) Support impact و Divergence Budget را پنهان نکن
support_owner، support_tier_impact و divergence_budget باید صریح باشند. fork هزینهٔ QA، incident handling و patch propagation دارد؛ این هزینه نباید زیر برچسب «یک customization کوچک» صفر فرض شود.
12) Core Evidence Contract
این درس 24 بُعد evidence دارد که 16 بُعد آن بحرانی است. جدول زیر baseline، branch-divergence و transfer را به‌صورت فشرده نشان می‌دهد؛ فایل JSON/CSV mapping کامل را نگه می‌دارد.
| customization_request_id | tenant_or_deploy_scope | canonical_core_ref | variation_type | extension_or_config_ref | compatibility_window | upgrade_test_ref | security_patch_path | support_owner | support_tier_impact | divergence_budget | fork_trigger | fork_exception_owner | sunset_or_rejoin_condition | decision_state | evidence_ref | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CR-101 | customer-a/prod | core@9.2 | DECLARATIVE_OVERLAY | overlay:customer-a:v2 | core>=9,<10 | test:overlay:9.2:PASS | canonical-first + rebuild-overlay | platform-customization | STANDARD | 0 source patches | source-divergence | patch-blocked | architecture-board | N/A_STANDARD | ACCEPT_STANDARD | ev:arc022:baseline |
| CR-202 | customer-b/prod | core@9.2 | SOURCE_PATCH | branch:customer-b | stale by 2 releases | test:rejoin:FAIL | manual cherry-pick | customer-b-squad | ESCALATED | exceeded | source-divergence | architecture-board | unproven | BLOCKED_SOURCE_DIVERGENCE | ev:arc022:fork-drift | |
| CR-303 | customer-c/prod | core@10.0 | UPSTREAM_PRODUCT_CHANGE | proposal:shared-capability:v1 | core>=10 | test:shared-capability:planned | canonical release train | core-platform | STANDARD_AFTER_UPSTREAM | 0 source patches | internal-api-coupling | architecture-board | N/A_UPSTREAM | UPSTREAM | ev:arc022:transfer |
13) Fork Exception فقط با Authority و Rejoin/Sunset
FORK_EXCEPTION مسیر عادی نیست. باید exception owner مشخص، trigger روشن، زمان/شرط rejoin یا sunset، patch path و support impact داشته باشد. fork بدون پایان تعریف‌شده یک fork دائمی با نام موقت است.
14) Typed state جلوی موفقیت جعلی را می‌گیرد
HOLD_EVIDENCE_MISSING، HOLD_CONFIG_UNBOUNDED، HOLD_COMPATIBILITY، BLOCKED_SOURCE_DIVERGENCE و BLOCKED_SECURITY_PATCH خروجی‌های معتبرند. کمبود evidence نباید با حدس به ACCEPT تبدیل شود.
15) Lab و Transfer
Lab هشت fixture و 48 assertion دارد. در transfer، extension schema عوض شده، fix امنیتی باید برای همه deployها برسد و request دوم به internal implementation detail وابسته است. learner باید تصمیم را از evidence جدید بازسازی کند؛ baseline هرگز oracle نیست.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ARC-022-S1 retrieval
What does ARC-022 own, and why is a customer-specific source branch not automatically a valid customization surface?
ARC-022-S2 application
Build Anti-fork Customization Decision Contract v1 for the baseline synthetic request and justify the decision from visible compatibility, patch, support and divergence evidence.
ARC-022-S3 diagnosis
A source patch exists only on one customer branch and the canonical core advances two releases. Which contract fields and states prevent false acceptance?
ARC-022-S4 transfer
The extension schema changes, an urgent security fix must reach every deployment, and Customer C asks for another change coupled to an internal detail. Recompute the path without copying the baseline decision.
ملاک‌های ارزیابی (rubric)
A passing artifact preserves a canonical core, classifies the variation surface, binds compatibility and upgrade evidence to explicit versions, proves a security-patch path, names support ownership and divergence budget, and keeps fork triggers plus rejoin/sunset conditions visible. Missing decisive evidence must remain HOLD/BLOCKED rather than acceptance.
منابع و تازگی
مطالعهٔ موارد (case studies)
A customer-specific presentation/policy change is implemented as a governed overlay against the canonical core with explicit upgrade and patch evidence.
A source patch is committed only to one customer branch while the canonical core advances, creating hidden divergence.
After an extension-schema change and urgent security fix, a second internal-detail request is recomputed as an upstream candidate instead of copied from the baseline.
تصاویر درس
فایل‌های آزمایشگاه
آزمایش کاملاً آفلاین و synthetic است. fixtures/cases.json را بررسی کنید، python run_checks.py را اجرا کنید و توضیح دهید چرا هر state از شواهد visible مربوط به customization، compatibility، upgrade، security، support و divergence به‌دست می‌آید. هیچ answer key یا credential واقعی وجود ندارد.