Microservices و Full Offline Studio Awareness

دو جهش معماری، دو مسئله‌ی مستقل

یک تیم کوچک را در نظر بگیرید که یک modular monolith نسبتاً منظم و یک content studio مبتنی بر مرورگر دارد. مدیریت پیشنهاد می‌کند برای «بلوغ معماری» هم‌زمان دو جهش انجام شود: شکستن سیستم به Microservices و ساخت Full Offline Studio. ظاهر پیشنهاد جذاب است، اما این دو انتخاب مسئله‌ی واحدی را حل نمی‌کنند و هیچ‌کدام صرفاً به‌خاطر بزرگ‌ترشدن محصول، تصمیم پیش‌فرض نیست.

برای Microservices باید فشار واقعی service decomposition را پیدا کنید: آیا چند تیم مستقل با domain boundaryهای روشن داریم؟ آیا release مستقل، scale مستقل یا failure isolation واقعاً لازم شده است؟ آیا distributed transaction risk و operational maturity را می‌توان مالکیت‌پذیر کرد؟ Microsoft Azure Architecture Center، Microservices را به‌عنوان سرویس‌های کوچک و autonomous هم‌راستا با business capability و bounded context توضیح می‌دهد و در کنار independent deployment/scaling، هزینه‌های distributed-system operations را هم برجسته می‌کند. این FACT ضرورت adoption را برای MAKNOW تعیین نمی‌کند. [MSMICRO]

برای Full Offline Studio باید مسئله‌ی دیگری را بسنجید: کاربر چه مدت باید disconnected بماند؟ آیا local write فقط cache/read است یا authoritative edit؟ sync چه زمانی و با چه policy انجام می‌شود؟ conflict چگونه resolve می‌شود؟ update، recovery و security boundary چه هستند؟ Service Worker می‌تواند fetch را intercept کند و تجربه‌های offline-enabled بسازد و IndexedDB persistent structured client-side storage می‌دهد؛ این capabilityها به‌تنهایی یک Full Offline Studio با sync/conflict/recovery تضمین نمی‌کنند. [SW] [IDB]

Artifact این درس Architecture Complexity Trigger and Offline-Studio Decision Record v1 است. دو record مستقل دارد: MICROSERVICES و FULL_OFFLINE_STUDIO. stateهای مجاز عبارت‌اند از USE، PILOT، NOT_NOW، UNKNOWN، EVIDENCE_INCOMPLETE، OWNER_MISSING، REVIEW_REQUIRED، HOLD، PARTIAL و DISPUTED. اگر evidence decisive ناقص باشد، success مجاز نیست؛ و اگر trigger به‌صورت اندازه‌گیری‌شده غایب باشد، NOT_NOW یک نتیجه‌ی معتبر است.

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

این درس برای کسی است که باید قبل از افزایش complexity، trigger، simpler alternative، owner، migration cost، failure surface و revisit evidence را قابل ممیزی کند.

این درس Microservices یا یک Offline Studio production-grade را deploy یا migrate نمی‌کند و outcome درس‌های Elasticsearch/OpenSearch/GraphQL یا Native/Billing/Tenancy را جذب نمی‌کند.

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

پیش از Fast Path، مرز مرتبط از AWR-001 را در یک جمله بیان کنید: چرا نام یا modernity یک فناوری trigger adoption نیست؟ سپس problem، measured trigger، simpler alternative و accountable owner/cost را از هم جدا کنید. اگر این چهار جزء را نمی‌توانید مستقل بیان کنید، Fast Path باز نیست.

پل محدود: فقط این evidence rule را بازیابی کنید: «technology name دلیل adoption نیست؛ مسئله، trigger قابل مشاهده، alternative ساده‌تر، owner و cost/failure boundary باید دیده شوند و NOT_NOW می‌تواند درست باشد.» این bridge outcome قبلی را جعل یا تکمیل نمی‌کند.

پیش‌نیاز SOFT — AWR-003

اگر AWR-003 را دارید، boundary مربوط به Elasticsearch/OpenSearch و GraphQL را یادآوری کنید: capability یک ابزار، به‌تنهایی authority برای architecture adoption بعدی نیست. ضعف در این یادآوری مانع ورود نیست، اما احتمال قاطی‌کردن adjacent outcomes را بالا می‌برد.

پل اختیاری: فقط overlap boundary را حمل کنید؛ search/API technology fit را وارد تصمیم Microservices یا Full Offline Studio نکنید. هدف این پل جلوگیری از scope absorption است، نه آموزش دوباره‌ی AWR-003.

اول pressure را تشخیص دهید، بعد architecture را

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

1. codebase بزرگ شده، اما هنوز یک تیم اصلی، یک release train و domain boundaryهای مبهم داریم. آیا «بزرگ‌شدن کد» به‌تنهایی Microservices را توجیه می‌کند؟
2. چند domain با ownerهای مستقل، release pressure مستقل و failure-isolation need داریم. آیا این evidence می‌تواند فقط record Microservices را تغییر دهد؟
3. یک Service Worker برای cache/read داریم، اما authoritative offline write و sync/conflict requirement نداریم. آیا این Full Offline Studio است؟
4. کاربران field باید یک شیفت کامل disconnected کار کنند و authoritative local edit بسازند. آیا بدون conflict policy می‌توان success state داد؟

۴ از ۴ → Fast Path. ۲ تا ۳ → Repair Path. ۰ تا ۱ → Foundation Path. Fast Path تعریف‌ها را کوتاه می‌کند، اما negative evidence، owner/cost، distributed/local-state obligations و transfer را حذف نمی‌کند.

خودسنجی: codebase size را team autonomy فرض نکنید؛ Service Worker را offline product architecture فرض نکنید؛ local storage را conflict policy ننامید؛ و «بلوغ» را evidence محسوب نکنید.

مدل ذهنی: دو زنجیره‌ی evidence

MICROSERVICES → problem class → team/domain evidence → independent deploy/scale/failure-isolation pressure → distributed consistency/operations burden → simpler modular-monolith alternative → owner + migration/failure surface → bounded state

FULL_OFFLINE_STUDIO → disconnected-duration requirement → authoritative local writes → sync + conflict policy → update/recovery/security → simpler online-first/offline-capable mode → owner + migration/failure surface → bounded state

این دو زنجیره به هم امتیاز نمی‌دهند. ممکن است Microservices PILOT و Full Offline Studio NOT_NOW باشد، یا برعکس. Decision state باید از evidence همان axis بیاید.

سه لایه را جدا کنید: FACT بیرونی mechanism/capability را توصیف می‌کند؛ evidence محلی problem/constraint را ثبت می‌کند؛ DESIGN در MAKNOW state vocabulary و acceptance gate را تعریف می‌کند. [MSMICRO]، [SW] و [IDB] FACT boundary را پشتیبانی می‌کنند؛ trigger threshold و use/not-now authority از طراحی MAKNOW می‌آید.

اگر diagram قابل رندر نبود، همین flow متنی text-equivalent کامل asset://AWR-004/AWR-004-ASSET-FLOW است.

Evidence Contract هر محور

MICROSERVICES

problem_class را دقیق بنویسید؛ سپس team_count را با bounded_context_evidence اشتباه نگیرید. تعداد تیم بدون domain ownership روشن، trigger کافی نیست. independent_deploy_need، independent_scale_need و failure_isolation_need را جدا کنید. distributed_transaction_risk و operational_maturity cost/riskهای adoption را visible می‌کنند. simpler_alternative باید واقعاً بررسی شود؛ برای بسیاری از pressureها modular monolith با boundary بهتر هنوز candidate ساده‌تر است. Microsoft overview امکان independent deployment/scaling و bounded contexts را توضیح می‌دهد، ولی adoption authority نیست. [MSMICRO]

FULL_OFFLINE_STUDIO

offline_duration_requirement را از «گاهی شبکه ضعیف است» جدا کنید. local_data_volume را جدا ثبت کنید تا محدوده‌ی working set/storage صریح باشد، نه ضمنی. offline_write_requirement باید مشخص کند آیا local edit authoritative است یا فقط cache/read. اگر write authoritative است، sync_requirement، conflict_policy، update_strategy، recovery_strategy و security_boundary decisive می‌شوند. Service Worker و IndexedDB mechanismهای browser هستند؛ وجود آن‌ها به‌تنهایی sync policy یا recovery guarantee تولید نمی‌کند. [SW] [IDB]

برای هر دو record، operational_owner، migration_cost، failure_surface، chapter_exit_evidence، review_due، rationale و stop_or_pivot_trigger را نگه دارید. همچنین authority_refs باید نشان دهد هر FACT/DESIGN claim از کجا آمده است.

ساخت Architecture Complexity Trigger and Offline-Studio Decision Record v1

گام ۱: دو record مستقل بسازید. score مشترک «architecture maturity» ممنوع است.

گام ۲: Microservices pressure را از symptoms سطحی جدا کنید. codebase size، تعداد repository یا تعداد endpoint به‌تنهایی در Contract trigger نیستند. evidence معتبر باید به autonomous team/domain boundary و independent release/scale/failure-isolation pressure وصل شود. اگر bounded context مبهم است یا deploy pressure حل‌نشده است، success را متوقف کنید.

گام ۳: distributed cost را visible کنید. microservices می‌تواند communication، observability، consistency و operational obligations را افزایش دهد؛ پس distributed_transaction_risk و operational_maturity باید همراه adoption evidence دیده شوند. [MSMICRO]

گام ۴: Full Offline requirement را از offline-capable feature جدا کنید. cache، read-only snapshot یا local draft می‌تواند alternative محدود باشد. Full Offline Studio وقتی معنا پیدا می‌کند که disconnected duration و authoritative local write واقعاً نیاز باشند و sync/conflict/update/recovery/security policy قابل دفاع باشد. [SW] [IDB]

گام ۵: simpler alternative را جدی بگیرید. برای Microservices، modular monolith با domain boundary روشن را بررسی کنید. برای Offline، online-first با cache/read یا bounded local draft را بررسی کنید. Alternative فقط وقتی رد می‌شود که evidence نشان دهد requirement را پوشش نمی‌دهد.

گام ۶: owner و failure surface را قبل از state ثبت کنید. Microservices بدون accountable operational owner یا Full Offline بدون data/sync owner success نیست. migration cost و rollback/recovery path باید قبل از پذیرش complexity دیده شوند.

گام ۷: state را از evidence نتیجه بگیرید. USE و PILOT success state هستند و فقط با measured trigger + owner + cost/failure evidence مجازند. NOT_NOW وقتی معتبر است که trigger همان axis به‌صورت measured absent باشد و alternative ساده‌تر requirement را پاسخ دهد. evidence گمشده باید typed uncertainty باقی بماند.

Worked Example: proposal را به دو record بشکنید

یک product studio با modular monolith و browser editor داریم. تیم معماری می‌گوید «کد بزرگ شده، پس باید Microservices شود» و تیم محصول می‌گوید «Service Worker داریم، پس بهتر است Full Offline هم بشویم.» این دو shortcut را به evidence تبدیل کنید.

برای Microservices، اول بپرسید: چند team واقعاً autonomous هستند؟ آیا bounded contextها stable و ownerدارند؟ آیا independent deploy/scale یا failure isolation نیاز واقعی است؟ اگر پاسخ‌ها هنوز مبهم‌اند، codebase size فقط symptom است و success state قابل دفاع نیست. قبل از شکستن system، modular monolith boundary را به‌عنوان alternative نگه دارید.

برای Offline، بپرسید: disconnected duration چقدر است؟ آیا کاربر باید authoritative local edit بسازد؟ اگر نه و cache/read برای brief outage کافی است، Service Worker/IndexedDB capability نمی‌تواند به‌تنهایی Full Offline trigger شود. اگر write لازم شد، بدون conflict/update/recovery policy decision هنوز کامل نیست. [SW] [IDB]

جدول asset://AWR-004/AWR-004-ASSET-TABLE باید reviewer را قادر کند هر state را از row evidence بازسازی کند. این مثال fixture answer key نیست؛ در Lab stateها prefilled نیستند و باید از exact shipped evidence ساخته شوند.

Failure Modeهای رایج

1. Codebase-size fallacy: بزرگ‌شدن repository را به autonomous-domain pressure تبدیل می‌کنید. Repair: team/domain/release evidence را جدا اندازه بگیرید.
2. Service Worker = Full Offline: fetch interception یا cache را معادل authoritative offline editing می‌گیرید. Repair: offline write، sync، conflict، update/recovery و security را صریح کنید. [SW] [IDB]
3. Missing owner → success: owner عملیاتی یا data/sync owner مشخص نیست، ولی state را PILOT می‌کنید. Repair: OWNER_MISSING یا state غیرموفق typed را حفظ کنید.
4. Unknown → NOT_NOW: evidence decisive نامعلوم است، اما برای راحتی NOT_NOW می‌زنید. NOT_NOW فقط measured absence است؛ unknown باید unknown بماند.
5. Adjacent scope absorption: search/API یا Native/Billing/Tenancy را به این درس می‌کشید. Repair: owned boundary V13/C01 را بازگردانید.
6. Vendor fact → MAKNOW authority: capability document را adoption verdict می‌گیرید. Repair: FACT و DESIGN را در authority refs جدا کنید.

Bridge برای افراد باتجربه: تعریف‌ها را کوتاه، evidence را کامل نگه دارید

اگر Microservices و offline architecture را می‌شناسید، بخش مقدماتی را فشرده کنید اما این پنج سؤال را حذف نکنید:

• pressure همان axis دقیقاً چیست و چگونه measured شده؟
• simpler architecture واقعاً کجا کم می‌آورد؟
• owner چه کسی است و چه failure surfaceی را می‌پذیرد؟
• کدام evidence FACT و کدام rule DESIGN است؟
• چه چیزی تصمیم را stop/pivot/review می‌کند؟

Experienced Path مجوز پایین‌آوردن evidence bar نیست. trade-off defense، negative case و changed-context transfer باید همان‌قدر auditable بمانند.

Alternativeها را قبل از complexity jump مقایسه کنید

Modular Monolith در برابر Microservices

اگر مشکل اصلی boundary clarity است، modular monolith با module ownership و interfaceهای روشن ممکن است alternative ساده‌تر باشد. Microservices زمانی قابل دفاع‌تر می‌شود که autonomous domain/team structure و independent release/scale/failure-isolation pressure واقعاً وجود داشته باشد و distributed operational cost پذیرفته شود. [MSMICRO]

Offline-capable در برابر Full Offline Studio

اگر requirement فقط brief outage، cached read یا local draft محدود است، online-first/offline-capable mode ممکن است کافی باشد. Full Offline Studio بار بیشتری دارد: authoritative local writes، sync، conflict policy، update/recovery و security. Service Worker و IndexedDB pieces ممکن‌اند، اما product decision کامل نیستند. [SW] [IDB]

Trade-off را به «کدام فناوری بهتر است؟» تقلیل ندهید. سؤال درست این است: «کدام architecture کمترین complexity لازم برای requirement اثبات‌شده را با owner و recovery قابل‌دفاع فراهم می‌کند؟»

Guided Practice و Independent Practice

Lab آفلاین lab://AWR-004/AWR-004-LAB1 را اجرا کنید. تمام fixtureها synthetic و read-only هستند. learner starter فقط structure و rule vocabulary را می‌دهد و هیچ verdict آماده‌ای ندارد.

Guided pass:

1. یک fixture را انتخاب کنید.
2. دو record MICROSERVICES و FULL_OFFLINE_STUDIO را از exact evidence بسازید.
3. rationale، review_due و stop_or_pivot_trigger را خودتان بنویسید.
4. checker را اجرا کنید و هر failed rule را به field مشخص برگردانید.

Independent pass: mutationهای codebase-size، offline-without-conflict، service-worker-cache-only، owner-missing و missing-evidence را بدون کپی baseline تحلیل کنید. هدف، پیدا کردن «جواب مخفی» نیست؛ هدف consistency بین evidence و state است.

Fast Path می‌تواند مستقیم به این بخش بیاید، اما prerequisite HARD AWR-001 باید قبلاً قابل بیان باشد و AWR-003 SOFT context نباید با owned outcome مخلوط شود.

چه چیزی evidence قابل پذیرش می‌سازد؟

Artifact کامل باید برای هر axis حداقل این دسته‌ها را visible کند: problem class، measured trigger fields، simpler alternative، operational/data owner، migration cost، failure surface، decision state، chapter-exit evidence، review due و stop/pivot trigger. برای Microservices، team/domain/deploy/scale/failure-isolation و distributed risk decisive هستند. برای Offline، duration، local_data_volume، write/sync/conflict/update/recovery/security decisive هستند. هر row همچنین problem صریح و rationale یادگیرنده را حمل می‌کند.

authority_refs نیز بخشی از evidence است: FACTهای Microservices به MSMICRO و claim AWR-004-K1 trace می‌شوند؛ browser offline mechanisms به SW/IDB و AWR-004-K2؛ Full Offline definition و adoption gates به DESIGN claimهای AWR-004-K3 و AWR-004-K4.

Checker فقط exact fixture binding و rule consistency را بررسی می‌کند؛ rationale انسانی باید نشان دهد چرا state از evidence قوی‌تر نیست. AI می‌تواند supplied evidence را مرتب کند، اما owner یا measured trigger را اختراع نمی‌کند.

Assessment و Transfer

AWR-004-F1: owned boundary + یک non-goal را بازیابی کنید.

AWR-004-F2: mutation «codebase بزرگ‌تر بدون team autonomy/deploy pressure/bounded-context evidence» را diagnose کنید و field/state نامعتبر و minimal repair را بنویسید.

AWR-004-F3: changed context را recompute کنید؛ baseline state را کپی نکنید.

AWR-004-S1: boundary و non-goal را توضیح دهید.

AWR-004-S2: از baseline fixture، Architecture Complexity Trigger and Offline-Studio Decision Record v1 را کامل بسازید.

AWR-004-S3: codebase-size shortcut را diagnose کنید.

AWR-004-S4: محصول دوم چند autonomous team با bounded domain و independent release pressure دارد؛ هم‌زمان field users باید یک شیفت کامل disconnected کار کنند و authoritative local edits بسازند. هر دو decision را مستقل recompute کنید و owner، alternative، migration/failure surface و review trigger را دفاع کنید.

Transfer زمانی پاس است که تغییر context واقعاً evidence هر axis را تغییر دهد؛ «هر دو حالا mature شده‌اند» پاسخ قابل قبول نیست.

منابع و Freshness Boundary

MSMICRO — Microsoft Azure Architecture Center، overview رسمی Microservices: bounded contexts، autonomous services، independent deployment/scaling و operational challenges. [MSMICRO]

SW — W3C Service Workers specification: fetch interception و mechanismهای offline-enabled web applications. [SW]

IDB — W3C IndexedDB specification family: persistent client-side structured storage. [IDB]

این سه منبع در 2026-09-03 برای claim boundaryهای همین درس ثبت شده‌اند و review بعدی 2026-12-02 است. آن‌ها mechanism/capability FACT را پشتیبانی می‌کنند؛ trigger threshold، state vocabulary و MAKNOW adoption gate از DESIGN authority درس می‌آیند. اگر semantics منبع پیش از تاریخ review materially تغییر کند، claim مربوط باید دوباره بررسی شود؛ هیچ claim جدیدی در این درس فراتر از boundaryهای فوق اضافه نشده است.