Posts

NetArchTest : Architecture as Code

Image
 لو إنت لسه بتبدأ، أكيد سمعت جملة "الكود ده ريحته وحشة" (Code Smells). الـ NetArchTest هي الأداة اللي بتركب "فلاتر" على الكود بتاعك عشان الريحة دي متظهرش أصلاً. هي Library بتسمحلك تكتب Architecture as Code . 1. ليه أصلاً نحتاج NetArchTest؟ (السيناريو المرعب) تخيل عندك موديول الـ Orders . المفروض إنه ميعرفش حاجة عن موديول الـ Payments إلا من خلال Events . جِه مبرمج جديد "عفوي" وقام كاتب سطر واحد بس: في لحظة، الموديولين بقوا "ملزوقين في بعض" (Tightly Coupled). لو جيت في المستقبل تشيل موديول الدفع عشان تغيره، موديول الطلبات هيقع معاك. الـ NetArchTest مهمته يمنع السطر ده إنه يتكتب أصلاً. 2. إزاي نبدأ؟ (التركيب والتجهيز) أول حاجة، إنت بتعمل مشروع XUnit أو NUnit عادي خالص جوه الـ Solution وتسميه Architecture.Tests . وبنزل الـ Package دي: Install-Package NetArchTest.eNhancedEdition ملحوظة: النسخة الـ eNhancedEdition فيها مميزات أكتر وتصليح لمشاكل كانت في النسخة القديمة. 3. القواعد الأساسية (The Big Four) الـ NetArchTest بيشتغل بمنطق 4 خطوات: Types...

إزاي تربط GA4 بـ Azure وتطلع Dashboard

Image
  الـ Blueprint الكامل: إزاي تربط GA4 بـ Azure وتطلع Dashboard 1. اللعبة ماشية إزاي؟ (The Big Picture) الفكرة إننا مش عاوزين نعتمد على تقارير Google Analytics الجاهزة بس، إحنا عاوزين "نملك" البيانات عشان نربطها ببيانات المبيعات أو الـ CRM اللي عندنا في Azure. المصدر: Google Analytics 4 (GA4). الناقل: Azure Data Factory (الأتوبيس اللي بينقل البيانات). المخزن: Azure Data Lake & Synapse (المخزن والورشة اللي بنصنف فيها). الواجهة: Power BI (اللوحة اللي بتنور للـ Management). 2. خطوات التنفيذ (The Pipeline) أ. مرحلة "تجميع الداتا" (Data Collection & Export) GA4 to BigQuery: جوجل مبيسمحش بسحب بيانات الـ Raw data لـ Azure مباشرة بسهولة. الحل إنك تفعل الـ Free Export لـ BigQuery . دي أول محطة للبيانات الخام. Azure Data Factory (ADF): ده "المايسترو". هتعمل Linked Service توصله بـ BigQuery عشان يسحب البيانات يومياً (Daily Ingestion) ويرميها في Azure. ب. مرحلة "المخزن والفرز" (Storage & Medallion Architecture) جوه Azure، مش بنرمي البيانا...

Modular Monolith — Cheat Sheet

🎯 يعني إيه Modular Monolith؟ تطبيق واحد Deploy واحد Runtime واحد متقسم داخليًا لوحدات (Modules) مستقلة فكّر فيه: Microservices في الدماغ Monolith في التنفيذ 🧩 التقسيم الصح ❌ Controllers / Services / Repositories ✅ Business Capabilities Orders | Inventory | Billing | Users | Notifications كل Module: مسؤولة عن Business واحد مالكة منطقها وداتاها 📁 Folder Structure النموذجي Module ├─ Application (Use cases) ├─ Domain (Entities, Rules) ├─ Infrastructure (DB, Repos) ├─ API (Controllers) └─ Module.cs (Registration) 🔒 القواعد الذهبية ❌ مفيش Module تكلم DB بتاعة غيرها ❌ مفيش Classes مشتركة عشوائي ✅ التواصل يتم من خلال API أو Events فقط 🔁 طرق التواصل 1️⃣ Synchronous (Direct Call) Interface Dependency Injection In-memory Fast 📌 استخدمه: Core business Reads عمليات لازم ترجع فورًا ⚠️ عيبه: Strong Coupling Cascading Failures 2️⃣ Asynchronous (Messaging) Events / Commands Fire-and-forget Message Contracts 📌 استخدمه: Side Effects Integrations Fault Isolation ⚠️ عيبه:...
الـ Modular Monolith بيتعمل إزاي؟ (بـ Folder Structure + Diagram + شرح مصطلحات) أولًا: الـ Folder Structure (نضيف وعالوضع) نفترض إننا شغالين على سيستم E-Commerce بسيط: Plaintext /src ├─ /BuildingBlocks (الأساسيات اللي الكل بيستخدمها) │ ├─ /Messaging (شغل الربط) │ │ ├─ IEvent.cs │ │ ├─ IEventBus.cs │ │ └─ OutboxMessage.cs │ ├─ /Domain (القواعد العامة) │ │ └─ Entity.cs │ └─ /Infrastructure (التعامل مع الداتا) │ └─ DbContextBase.cs │ ├─ /Modules (قلب السيستم) │ ├─ /Orders (موديول الطلبات) │ │ ├─ OrdersModule.cs │ │ ├─ /Application (الـ Use Cases) │ │ ├─ /Domain (الـ Logic بتاع الـ Orders) │ │ │ ├─ Order.cs │ │ │ └─ Events │ │ │ └─ OrderPlacedEvent.cs │ │ ├─ /Infrastructure (الـ Database الخاصة بالـ Orders) │ │ │ └─ OrdersDbContext.cs │ │ └─ /API (الـ Controllers) │ │ │ ├─ /Inventory (موديول المخازن) │ │ ├─ InventoryModule.cs │ │ └─ ... (نفس التقسيمة) │ │ │ └─ /Notifica...