آموزش تبدیل شدن به معمار داده: طراحی، تصمیم‌گیری و دفاع از پلتفرم‌ها - آخرین آپدیت

سرفصل ها و درس ها

کار واقعی معماران چیست - تصمیم‌گیری، نه فقط ساختن What Architects Actually Do — Deciding, Not Building

• وظیفه معمار: تصمیم‌گیری در شرایط عدم قطعیت در برابر ساختن چیز درست The Architect's Job: Deciding Under Uncertainty vs. Building the Right Thing

• درک مشکل واقعی: نیازمندی‌ها و محدودیت‌ها - تأخیر، هزینه، انطباق، مهارت‌ها و زمان‌بندی Reading the Real Problem: Requirements & Constraints — Latency, Cost, Compliance, Skills, Timeline

• ساختن در برابر خریدن در برابر ترکیب: چارچوب اصلی تصمیم‌گیری معماری Build vs. Buy vs. Compose: The Core Architecture Decision Framework

• گفتگو با مدیران ارشد: بحث توازن‌ها با CFO / CISO / CTO Speaking to Power: The CFO / CISO / CTO Trade-off Conversation

تکامل معماری داده (چه زمانی کدام یک برنده است) The Evolution of Data Architecture (Which Wins When)

• چرا معماری‌ها مدام تغییر می‌کنند (و چرا معماری شما هم تغییر خواهد کرد) Why Architectures Keep Changing (and Why Yours Will Too)

• از Warehouse به Lake و سپس Lakehouse (سلسله‌مراتب متمرکز) Warehouse → Lake → Lakehouse (The Centralized Lineage)

• Mesh و Fabric (سلسله‌مراتب غیرمتمرکز) Mesh & Fabric (The Decentralized Lineage)

• پشته داده مدرن (Modern Data Stack) و پرسش ساختن در برابر خریدن یا ترکیب The Modern Data Stack & the Build-vs-Buy-vs-Compose Question

• کدام الگو چه زمانی برنده است (سنتز و تز نهایی) Which Pattern Wins When (Synthesis + the Thesis)

معماری مرجعی که می‌توانید روی تخته رسم کنید (بخش اول) The Reference Architecture You Can Draw on a Whiteboard (Act 1)

• لایه‌های استاندارد: منبع -> ورود -> ذخیره -> تبدیل -> سرویس -> مصرف The Canonical Layers: Source → Ingest → Store → Transform → Serve → Consume

• رسم از حافظه: تمرین تخته سفید به عنوان یک مهارت Drawing It From Memory: The Whiteboard Exercise as a Skill

• یک نمودار واحد، Monolith در برابر Mesh: بازرسم به صورت غیرمتمرکز The Same Diagram, Monolith vs Mesh: Redraw It Decentralized

• محل قرارگیری تصمیمات هر لایه: کل دوره در قالب یک نمودار Where Each Layer's Decisions Live: The Course as One Diagram

• لایه‌بندی Batch و Stream: مقایسه Lambda در برابر Kappa در سطح مرجع Batch + Stream Layering: Lambda vs Kappa at the Reference Level

انتخاب لایه ذخیره‌سازی: ذخیره‌سازی شیء، فرمت‌ها و الگوهای دسترسی Choosing Your Storage Layer: Object Storage, Formats & Access Patterns

• ذخیره‌سازی شیء به عنوان بنیاد: چرا جداسازی ذخیره‌سازی از پردازش همه چیز را تغییر داد Object Storage as the Foundation: Why Decoupled Storage/Compute Changed Everything

• فرمت‌های فایل: Parquet در برابر ORC و Avro - تصمیم ستونی در برابر ردیفی File Formats: Parquet vs ORC vs Avro — The Columnar-vs-Row Decision

• سه الگوی دسترسی تعیین‌کننده ذخیره‌سازی: Hot، Warm، Cold و هزینه خروج داده (Egress) The 3 Access Patterns That Dictate Storage: Hot, Warm, Cold & the Cost of Egress

• پارتیشن‌بندی و اندازه فایل‌ها: مشکل فایل‌های کوچک که سرعت را می‌گیرد Partitioning & File Sizing: The Small-Files Problem That Crawls

• توازن‌های فشرده‌سازی و چیدمان: کاهش حجم بدون کند کردن خواننده Compression & Layout Trade-offs: Squeezing the Bytes Without Choking the Reader

مقایسه Delta در برابر Iceberg و Hudi: انتخاب فرمت جدول Delta vs Iceberg vs Hudi: Choosing Your Table Format

• چرا فرمت‌های جدول وجود دارند: ACID روی ذخیره‌سازی شیء Why Table Formats Exist: ACID on Top of Object Storage

• مقایسه Delta، Iceberg و Hudi: ماتریس تصمیم‌گیری Delta vs Iceberg vs Hudi: The Decision Matrix

• تکامل طرح (Schema Evolution) و سفر در زمان به عنوان معماری (نه فقط ویژگی) Schema Evolution & Time Travel as Architecture (Not Features)

• کاتالوگ باز و تعامل‌پذیری: وعده Lakehouse باز (و محدودیت‌های آن) The Open Catalog & Interop: The Open-Lakehouse Promise (and Its Limits)

• بازبینی معماری ۱ (مبنی بر فرمت جدول و ذخیره‌سازی) Architecture Review #1 (Table-Format & Storage Anchored)

مدل‌سازی ابعادی - بینشی که کسی آموزش نمی‌دهد Dimensional Modeling — The Insight Nobody Teaches

• فکت‌ها و ابعاد - و چرا تعیین سطح جزئیات (Grain) اولویت دارد Facts & Dimensions — and Why Grain Comes First

• طرح ستاره‌ای در برابر Snowflake - و تله هزینه نرمال‌سازی بیش از حد Star vs Snowflake — and the Over-Normalization Cost Trap

• ابعاد با تغییر کند (SCD) - انواع SCD به عنوان تصمیمات معماری Slowly Changing Dimensions — SCD Types as Decisions

• بینش Grain - قبل از مدل‌سازی آن را اعلام کنید The Grain Insight — Declare It Before You Model

• ابعاد هماهنگ و ماتریس اتوبوس (مدل‌سازی در سطح سازمان) Conformed Dimensions & the Bus Matrix (Modeling Across an Enterprise)

فراتر از طرح‌های ستاره‌ای (چه زمانی Vault، Wide یا OBT را انتخاب کنیم) Beyond Star Schemas (When to Choose Vault, Wide, or OBT)

• دیتا والت (Data Vault): زمانی که قابلیت حسابرسی و بارگذاری موازی برنده است Data Vault: When Auditability & Parallel Loading Win

• یک جدول بزرگ (OBT) به عنوان پیش‌فرض انبار داده ابری One Big Table (OBT) as the Cloud-Warehouse Default

• جداول پهن (Wide Tables) و اقتصاد غیرنرمال‌سازی Wide Tables & the Economics of Denormalization

• انتخاب پارادایم مدل‌سازی - ماتریس تصمیم‌گیری Choosing Your Modeling Paradigm — A Decision Matrix

تصمیمات ورود داده: دسته‌ای در برابر افزایشی و CDC Ingestion Decisions: Batch vs Incremental vs CDC

• درخت تصمیم ورود داده (قبل از نوشتن هرگونه خط لوله) The Ingestion Decision Tree (Before You Write Any Pipeline)

• الگوهای بارگذاری دسته‌ای و حجیم: Truncate، Reload و Partition Swap Batch and Bulk Load Patterns: Truncate, Reload, and Partition Swap

• بارگذاری افزایشی و واترمارکی که باعث حذف ردیف‌ها شد Incremental Loading and the Watermark That Dropped Rows

• جذب تغییرات داده (CDC): Log در برابر Query در برابر Trigger Change Data Capture: Log vs Query vs Trigger

• بازبینی معماری ۲: ورود داده ترکیبی برای یک خرده‌فروشی با ۲۰۰ فروشگاه Architecture Review #2: Mixed Ingestion for a 200-Store Retailer

آیا این مورد اصلاً باید استریمینگ باشد؟ - توازن‌های زمان واقعی Should This Be Streaming At All? — Real-Time Trade-offs

• توهم زمان واقعی: تأخیر یک تصمیم تجاری است The Real-Time Illusion: Latency Is a Business Decision

• اجزای معماری استریمینگ: Log، Processor و Sink Streaming Architecture Components: Log, Processor, Sink

• دقیقاً یک‌بار در برابر حداقل یک‌بار: انتخاب معمار Exactly-Once vs At-Least-Once: The Architect's Choice

• زمانی که استریمینگ ارزشش را ندارد: مالیات پیچیدگی When Streaming Is NOT Worth It: The Complexity Tax

• مقایسه Lambda و Kappa: یکپارچه‌سازی دسته‌ای و استریم Lambda vs Kappa: Unifying Batch & Stream

معماری تبدیل داده: ELT، الگوی Medallion و پارادایم dbt Transformation Architecture: ELT, Medallion & the dbt Paradigm

• مقایسه ETL و ELT: چرا T جابجا شد (پردازش در جایی که داده‌ها هستند) ETL vs ELT: Why the T Moved (Compute-Where-the-Data-Is)

• الگوی Medallion: برنز / نقره / طلا (و تضمین هر لایه) The Medallion Pattern: Bronze / Silver / Gold (and What Each Layer Guarantees)

• پارادایم dbt: تبدیل به عنوان کد (ماژولار بودن، تست‌ها، مستندات و Lineage) The dbt Paradigm: Transformation as Code (Modularity, Tests, Docs, Lineage)

• قراردادهای داده به عنوان کد (پلی به کیفیت در M13 و DataOps در M11) Data Contracts as Code (Bridge to M13 Quality and M11 DataOps)

• Idempotency و پردازش مجدد در تبدیل‌ها (اجرای مجدد ایمن) Idempotency & Reprocessing in Transforms (Safe Re-Runs; Callback M08)

دیتا اپس (DataOps) و مهندسی پلتفرم - جایی که معماران به رهبران مهندسی تبدیل می‌شوند DataOps & Platform Engineering — Where Architects Become Engineering Leaders

• چرا DataOps: دیسیپلینی که معماران را از سازندگان خط لوله جدا می‌کند Why DataOps: The Discipline That Separates Architects From Pipeline-Builders

• سی‌آی/سی‌دی (CI/CD) برای خطوط لوله داده: تست در خط لوله و گیت‌های استقرار CI/CD for Data Pipelines: Testing in the Pipeline & Deploy Gates

• زیرساخت به عنوان کد (IaC) و GitOps: پلتفرم به عنوان کد با کنترل نسخه Infrastructure as Code & GitOps: The Platform as Version-Controlled Code

• ارتقای محیط: توسعه -> استیجینگ -> عملیات (داده + طرح + پیکربندی) Environment Promotion: dev → staging → prod (Data + Schema + Config)

• استقرار Blue/Green در برابر Canary برای داده‌ها: استراتژی‌های استقرار و مسیر مشاهده‌پذیری Blue/Green vs Canary for Data: Deployment Strategies & the Path to Observability

ارکستراسیون، متادیتا و Lineage: سیستم‌عامل پلتفرم Orchestration, Metadata & Lineage: The Platform Operating System

• الگوهای ارکستراسیون: DAGها و مدیریت وابستگی‌ها Orchestration Patterns: DAGs & Dependency Management

• ارکستراسیون زمان‌بندی شده در برابر رویداد-محور: تصمیم‌گیری Scheduled vs Event-Driven Orchestration: The Decision

• متادیتا به عنوان سیستم عصبی پلتفرم Metadata as the Platform's Nervous System

• Lineage: دانستن اینکه چه چیزی چه چیزی را می‌شکند (تحلیل اثر) Lineage: Knowing What Breaks What (Impact Analysis)

• کاتالوگ: مرکز کشف و حاکمیت داده The Catalog: Discovery & Governance Hub

کیفیت داده و قراردادها: چه مقدار کیفیت کافی است؟ Data Quality & Contracts: How Much Quality Is Enough?

• هزینه داده‌های بد: چرا اعتماد، محصول اصلی است The Cost of Bad Data: Why Trust Is the Product

• تست Shift Left: شناسایی خطا در مبدأ (تولیدکننده) Shift-Left Testing: Catch It at the Producer

• قراردادهای داده: توافق بین تولیدکننده و مصرف‌کننده Data Contracts: The Producer-vs-Consumer Agreement

• تکامل طرح و تغییرات شکست‌دهنده: نسخه‌بندی و سازگاری Schema Evolution & Breaking Changes: Versioning & Compatibility

• SLAهای کیفیت: چه مقدار کافی است و کجا باید اجرا شود Quality SLAs: How Much Is Enough & Where to Enforce

امنیت و حاکمیت: چه مقدار امنیت کافی است؟ Security & Governance: How Much Security Is Enough?

• معماری دسترسی: RBAC در برابر ABAC در برابر RLS - کدام مدل مناسب است؟ The Access Architecture: RBAC vs ABAC vs RLS — Which Model Fits?

• سیاست به عنوان کد: حاکمیتی که مقیاس‌پذیر است و از حسابرسی می‌گذرد Policy as Code: Governance That Scales and Survives an Audit

• حاکمیت فدرال: مدیریت بدون نیاز به یک تیم متمرکز و یکپارچه Federated Governance: Governing Without a Monolithic Team

• انطباق بر اساس طراحی: PII، نگهداری و حق فراموش شدن Compliance by Design: PII, Retention & the Right to Be Forgotten

• چه مقدار امنیت کافی است؟ تصمیم بین اصطکاک و ریسک How Much Security Is Enough? The Friction vs Risk Decision

معماری هزینه: طراحی بر اساس بودجه Cost Architecture: Designing to a Budget

• هزینه یک تصمیم معماری است، نه یک فکر بدیع Cost Is an Architectural Decision, Not an Afterthought

• اقتصاد ذخیره‌سازی: Hot، Warm، Cold و مالیات ۵ برابری نگهداری Storage Economics: Hot, Warm, Cold, and the 5x Retention Tax

• اقتصاد پردازش و کوئری: چرا ابعاد بزرگتر می‌تواند هزینه کمتری داشته باشد Compute & Query Economics: Why Bigger Can Cost Less

• انتقال داده و تله خروج (Egress): خطی که هیچ‌کس ترسیم نمی‌کند Data Transfer & the Egress Trap: The Line Nobody Charts

• الگوهای هزینه کوئری و حجم کاری: زمانی که غیرنرمال‌سازی ارزان‌تر است Query & Workload Cost Patterns: When Denormalization Is Cheaper

• بازبینی معماری ۳: کارگاه تخمین هزینه Architecture Review #3: The Cost Estimation Workshop

معماری عملکرد: بهینه‌سازی بر اساس حجم کاری (Workload) Performance Architecture: Tuning by Workload

• چیزی به نام «سریع» وجود ندارد - فقط سرعت متناسب با حجم کاری There Is No "Fast" — Only Fast For A Workload

• حجم‌های کاری BI: خوشه‌بندی، متریالیزه کردن و کش کردن نتایج BI Workloads: Clustering, Materialization & Result Caching

• حجم‌های کاری ETL: توان عملیاتی، موازی‌سازی و اندازه فایل‌ها ETL Workloads: Throughput, Parallelism & File Sizing

• حجم‌های کاری Ad hoc و علوم داده: ایزوله‌سازی و الاستیک بودن Ad-hoc & Data-Science Workloads: Isolation & Elasticity

• پارتیشن‌بندی، خوشه‌بندی و کشینگ به عنوان اهرم هزینه و عملکرد Partitioning, Clustering & Caching as a Cost + Performance Lever

لایه سرویس‌دهی: BI، لایه معنایی، Reverse ETL و APIهای داده The Serving Layer: BI, Semantic Layer, Reverse ETL & Data APIs

• چهره‌های مختلف «سرویس‌دهی»: چه کسی داده‌های شما را چگونه مصرف می‌کند The Many Faces of 'Serving': Who Consumes Your Data and How

• جنگ لایه معنایی: Looker در برابر dbt Semantic Layer در برابر Cube The Semantic Layer Wars: Looker vs dbt Semantic Layer vs Cube

• Reverse ETL: تحلیل‌های عملیاتی (بازگرداندن داده‌های انبار به ابزارها) Reverse ETL: Operational Analytics (Pushing Warehouse Data Back to the Tools)

• APIهای داده و سرویس‌دهی داده به عنوان محصول Data APIs & Data-as-a-Product Serving

قابلیت اطمینان، مقیاس‌پذیری و بازیابی فاجعه (DR) در چندین منطقه Reliability, Scale & Multi-Region DR

• SLAها، SLOها و بودجه خطا برای داده‌ها: انتخاب عدد مناسب SLAs, SLOs & Error Budgets for Data: Choosing the Number

• مشاهده‌پذیری و پاسخ به حوادث: شناسایی -> تشخیص -> بازیابی Observability & Incident Response: Detect → Diagnose → Recover

• الگوهای مقیاس‌پذیری - عمودی، افقی و الاستیک: تصمیم بر اساس حجم کاری Scaling Patterns — Vertical, Horizontal & Elastic: The Decision by Workload

• چند منطقه‌ای و بازیابی فاجعه: RPO/RTO به عنوان معماری Multi-Region & Disaster Recovery: RPO/RTO as Architecture

• تک‌مستاجری در برابر چندمستاجری: ایزوله‌سازی در برابر بهره‌وری Tenancy — Single vs Multi-Tenant: Isolation vs Efficiency

مش داده (Data Mesh) و محصولات داده: تمرکززدایی بدون هرج‌ومرج Data Mesh & Data Products: Decentralizing Without Chaos

• چهار اصل مش داده (Data Mesh): تمرکززدایی بدون هرج‌ومرج The Four Principles of Data Mesh: Decentralizing Without Chaos

• محصول داده چیست؟ مرزها، قراردادها، SLOها و قابلیت کشف What Is a Data Product? Boundaries, Contracts, SLOs & Discoverability

• چرخه عمر محصول داده: کشف -> طراحی -> ساخت -> انتشار -> بهره‌برداری -> بازنشستگی The Data Product Lifecycle: Discover → Design → Build → Publish → Operate → Retire

• پلتفرم داده سلف-سرویس: توانمندسازی دامین‌ها بدون متمرکز کردن The Self-Serve Data Platform: Enabling Domains Without Centralizing

• زمانی که Mesh شکست می‌خورد: مشی که به هرج‌ومرج تبدیل شد (و چه زمانی نباید آن را به کار برد) When Mesh Fails: The Mesh That Became a Mess (and When NOT to Adopt It)

معماری برای AI: تصمیمات پلتفرمی که باعث موفقیت یا شکست می‌شوند Architecting for AI: The Platform Decisions That Make or Break It

• ارزیابی آمادگی AI: آیا واقعاً آماده هستید؟ The AI Readiness Assessment: Are You Even Ready?

• چرا AI پلتفرم داده شما را می‌شکند: مشکل دو سرعت Why AI Breaks Your Data Platform: The Two-Speed Problem

• Feature Store: معماری برای سازگاری بین آموزش و سرویس‌دهی The Feature Store: Architecting for Training-Serving Consistency

• Embeddings و پایگاه‌داده‌های برداری: معماری بازیابی در مقیاس بالا Embeddings & Vector Databases: Architecting Retrieval at Scale

• الگوهای RAG و سرویس‌دهی LLM: جایی که پلتفرم با مدل ملاقات می‌کند RAG & LLM Serving Patterns: Where the Platform Meets the Model

• حاکمیت AI، Lineage و هزینه: نرده‌های حفاظتی برای سیستم‌های احتمالی AI Governance, Lineage & Cost: Guardrails for Probabilistic Systems

• کارگاه بازبینی معماری: طراحی یک پلتفرم آماده برای AI Architecture Review Workshop: Design an AI-Ready Platform

سندهای ADR، ضد-الگوها و تجربیات واقعی ADRs, Anti-Patterns & War Stories

• سند تصمیمات معماری (ADR): تصمیم‌گیری در فضای باز The Architecture Decision Record: Deciding in the Open

• کاتالوگ ضد-الگوها (معماران خوب چگونه اشتباه می‌کنند) The Anti-Pattern Catalog (How Good Architects Go Wrong)

• داستان واقعی: کوئری ۵۰ هزار دلاری و زخم‌های هزینه War Story: The $50k Query & the Cost Scars

• داستان واقعی: حلقه CDC و زخم‌های قابلیت اطمینان War Story: The CDC Loop & the Reliability Scars

• دفاع از معماری شما (بازبینی هیئت مدیره) Defending Your Architecture (The Board Review)

پروژه نهایی: طراحی و دفاع در برابر CFO و CISO Capstone: Design & Defend to a CFO and a CISO

• بریف: بررسی نیازمندی‌ها، محدودیت‌ها و دستورالعمل‌های AI یک شرکت واقعی The Brief: Reading a Real Company's Requirements, Constraints & AI Mandate

• طراحی معماری از ابتدا تا انتها: یک تصمیم برای هر لایه Designing the Architecture End-to-End: One Decision Per Layer

• بسته ADR: مستندسازی هر تصمیم بزرگ برای ماندگاری آن The ADR Package: Documenting Every Major Decision So It Survives

• دفاع در برابر هیئت مدیره: بازبینی کامل ۹ مرحله‌ای در برابر CFO، CISO و CTO The Board Defense: The Full 9-Part Architecture Review Against CFO, CISO & CTO

• سفر معماری شما: بازبینی تز نهایی و گام‌های بعدی Your Architecture Journey: The Thesis Revisited & Where to Go Next

آزمون‌های هر ماژول (مرور اختیاری) Module Quizzes (Optional Review)

• بررسی ماژول ۱: کار واقعی معماران چیست - تصمیم‌گیری، نه فقط ساختن Module 1 Check: What Architects Actually Do — Deciding, Not Building

• بررسی ماژول ۲: تکامل معماری داده (چه زمانی کدام یک برنده است) Module 2 Check: The Evolution of Data Architecture (Which Wins When)

• بررسی ماژول ۳: معماری مرجعی که می‌توانید روی تخته رسم کنید (بخش اول) Module 3 Check: The Reference Architecture You Can Draw on a Whiteboard (Act 1)

• بررسی ماژول ۴: انتخاب لایه ذخیره‌سازی: ذخیره‌سازی شیء، فرمت‌ها و الگوهای دسترسی Module 4 Check: Choosing Your Storage Layer: Object Storage, Formats & Access Patterns

• بررسی ماژول ۵: مقایسه Delta در برابر Iceberg و Hudi: انتخاب فرمت جدول Module 5 Check: Delta vs Iceberg vs Hudi: Choosing Your Table Format

• بررسی ماژول ۶: مدل‌سازی ابعادی - بینشی که کسی آموزش نمی‌دهد Module 6 Check: Dimensional Modeling — The Insight Nobody Teaches

• بررسی ماژول ۷: فراتر از طرح‌های ستاره‌ای (چه زمانی Vault، Wide یا OBT را انتخاب کنیم) Module 7 Check: Beyond Star Schemas (When to Choose Vault, Wide, or OBT)

• بررسی ماژول ۸: تصمیمات ورود داده: دسته‌ای در برابر افزایشی و CDC Module 8 Check: Ingestion Decisions: Batch vs Incremental vs CDC

• بررسی ماژول ۹: آیا این مورد اصلاً باید استریمینگ باشد؟ - توازن‌های زمان واقعی Module 9 Check: Should This Be Streaming At All? — Real-Time Trade-offs

• بررسی ماژول ۱۰: معماری تبدیل داده: ELT، الگوی Medallion و پارادایم dbt Module 10 Check: Transformation Architecture: ELT, Medallion & the dbt Paradigm

• بررسی ماژول ۱۱: دیتا اپس (DataOps) و مهندسی پلتفرم - جایی که معماران به رهبران مهندسی تبدیل می‌شوند Module 11 Check: DataOps & Platform Engineering — Where Architects Become Engineering Leaders

• بررسی ماژول ۱۲: ارکستراسیون، متادیتا و Lineage: سیستم‌عامل پلتفرم Module 12 Check: Orchestration, Metadata & Lineage: The Platform Operating System

• بررسی ماژول ۱۳: کیفیت داده و قراردادها: چه مقدار کیفیت کافی است؟ Module 13 Check: Data Quality & Contracts: How Much Quality Is Enough?

• بررسی ماژول ۱۴: امنیت و حاکمیت: چه مقدار امنیت کافی است؟ Module 14 Check: Security & Governance: How Much Security Is Enough?

• بررسی ماژول ۱۵: معماری هزینه: طراحی بر اساس بودجه Module 15 Check: Cost Architecture: Designing to a Budget

• بررسی ماژول ۱۶: معماری عملکرد: بهینه‌سازی بر اساس حجم کاری (Workload) Module 16 Check: Performance Architecture: Tuning by Workload

• بررسی ماژول ۱۷: لایه سرویس‌دهی: BI، لایه معنایی، Reverse ETL و APIهای داده Module 17 Check: The Serving Layer: BI, Semantic Layer, Reverse ETL & Data APIs

• بررسی ماژول ۱۸: قابلیت اطمینان، مقیاس‌پذیری و بازیابی فاجعه (DR) در چندین منطقه Module 18 Check: Reliability, Scale & Multi-Region DR

• بررسی ماژول ۱۹: مش داده (Data Mesh) و محصولات داده: تمرکززدایی بدون هرج‌ومرج Module 19 Check: Data Mesh & Data Products: Decentralizing Without Chaos

• بررسی ماژول ۲۰: معماری برای AI: تصمیمات پلتفرمی که باعث موفقیت یا شکست می‌شوند Module 20 Check: Architecting for AI: The Platform Decisions That Make or Break It

• بررسی ماژول ۲۱: سندهای ADR، ضد-الگوها و تجربیات واقعی Module 21 Check: ADRs, Anti-Patterns & War Stories

• بررسی ماژول ۲۲: پروژه نهایی: طراحی و دفاع در برابر CFO و CISO Module 22 Check: Capstone: Design & Defend to a CFO and a CISO