Voice Recognition
التعرف على الصوت

هي تقنية تسمح للأجهزة بفهم الكلام المنطوق وتحويله إلى نص مكتوب.

تخيل أنك تتحدث إلى هاتفك، فيقوم بفهم كلماتك ويقوم بتنفيذ ما تطلبه.

كيف تعمل؟

التسجيل:
يقوم الجهاز بتسجيل صوتك وتحويله إلى إشارة رقمية.

التحليل:
يتم تحليل الإشارة الرقمية للكشف عن النغمات والترددات المختلفة في صوتك.

المقارنة:
تقارن الخوارزميات النغمات والترددات المسجلة بقاعدة بيانات كبيرة من الأصوات والكلمات المعروفة.

التحويل:
يتم تحويل النمط الصوتي الأقرب إلى الكلمات المكتوبة وعرضها على الشاشة.

الخوارزميات المستخدمة:-

هناك العديد من الخوارزميات المعقدة المستخدمة في التعرف على الصوت، ولكن بشكل عام تعتمد على:

نماذج صوتية:
تمثل هذه النماذج الكلمات والأصوات المختلفة بلغة رياضية.

شبكات عصبية اصطناعية:
تتعلم هذه الشبكات من كميات هائلة من البيانات الصوتية لتحسين دقة التعرف.

خوارزميات البحث:
تساعد في العثور على أفضل تطابق بين الصوت المسجل وقاعدة البيانات.

أمثلة على استخدامات التعرف على الصوت:

مساعدات صوتية:
مثل سيري وجوجل أسسستنت.

الترجمة الفورية:
تحويل الكلام المنطوق إلى لغة أخرى.

أوامر صوتية:
التحكم في الأجهزة المنزلية الذكية.

إملاء النصوص:
كتابة الرسائل والبريد الإلكتروني بصوتك.

لماذا التعرف على الصوت مهم؟

سهولة الاستخدام:
يجعل التفاعل مع الأجهزة أكثر طبيعية وسهولة.

إمكانية الوصول:
يوفر طريقة بديلة للأشخاص ذوي الإعاقات البصرية.

كفاءة:
يوفر الوقت والجهد مقارنة بالكتابة.

تحديات التعرف على الصوت:

الضوضاء:
قد تؤثر الضوضاء الخلفية على دقة التعرف.

اللكنة:
قد تختلف اللهجات واللهجات مما يجعل التعرف أكثر صعوبة.

سرعة الكلام:
قد يؤثر التحدث بسرعة كبيرة على دقة التعرف.

مستقبل التعرف على الصوت:
مع التطور التكنولوجي المتسارع، من المتوقع أن يصبح التعرف على الصوت أكثر دقة وفعالية.

ستشمل التطورات المستقبلية:

تحسين دقة التعرف في بيئات صاخبة.

فهم اللغات المتعددة واللهجات المختلفة.

التعرف على العواطف والمشاعر من خلال الصوت.

تعلم الآلة (Machine Learning):

هو فرع من فروع الذكاء الاصطناعي يركز على تطوير أنظمة قادرة على التعلم من البيانات وتحسين أدائها بمرور الوقت دون الحاجة إلى برمجة صريحة لكل مهمة. تخيل أنك تعلم طفلًا جديدًا شيئًا ما، فبدلاً من إعطائه مجموعة قواعد صارمة، تسمح له بتجربة الأشياء بنفسه والتعلم من أخطائه ونجاحاته.
هذا هو بالضبط ما يفعله تعلم الآلة مع الأجهزة.

الأقسام الثلاثة الرئيسية لتعلم الآلة:

التعلم تحت الإشراف (Supervised Learning):

المبدأ:

يتم تدريب النظام على مجموعة بيانات تحتوي على المدخلات والمخرجات الصحيحة.

الهدف:

يتعلم النظام كيفية ربط المدخلات بالمخرجات الصحيحة، وبالتالي يمكنه التنبؤ بالمخرجات لمجموعة جديدة من البيانات.

أمثلة:

تصنيف البريد الإلكتروني إلى حمولة أو سبام.

التنبؤ بأسعار المنازل بناءً على مساحتها وموقعها.

التعرف على الأرقام المكتوبة بخط اليد.


التعلم غير المشرف (Unsupervised Learning):

المبدأ:

يتم تدريب النظام على مجموعة بيانات لا تحتوي على مخرجات صحيحة.

الهدف:

يكتشف النظام بنفسه الأنماط والعلاقات الخفية في البيانات.

أمثلة:

تجميع العملاء إلى مجموعات بناءً على سلوكهم الشرائي.

اكتشاف الاحتيال في بطاقات الائتمان.

تقليل الأبعاد في البيانات المعقدة.


التعلم المعزز (Reinforcement Learning):


المبدأ:

يتعلم النظام من خلال التفاعل مع بيئة.


الهدف:

يتعلم النظام اتخاذ أفضل سلسلة من الإجراءات لتحقيق مكافأة قصوى.


أمثلة:

تدريب روبوت للعب الشطرنج.

تطوير سيارات ذاتية القيادة.

تحسين استراتيجيات التسويق.

ليش أتعلم عن معاملات ACID؟ 🤔

يا صديقي، كلام مثل ACID مو مجرد مفاهيم نظرية نتعلمها وننساها. بالعكس، هو أساس في تطوير الأنظمة الآمنة والمستقرة، خاصة لما تكون البيانات حساسة والعمليات معقدة. خليني أوضحلك إيش بتستفيد:



1️⃣ ضمان أمان البيانات

ACID يعطيك إطار عمل يضمن أن البيانات ما تضيع ولا تتعرض لمشاكل مثل الانقطاع المفاجئ أو التداخل بين العمليات.
مثال: تخيّل لو كنت مطوّر نظام بنكي، لو العمليات ما كانت آمنة ومستقرة، ممكن تفقد أموال العملاء أو تصير أخطاء فادحة.


2️⃣ إدارة العمليات المتزامنة

لو عندك آلاف المستخدمين يتعاملون مع النظام في نفس اللحظة، ACID يساعدك تتأكد أن كل عملية تتم بشكل مستقل وما تتداخل مع غيرها.
مثال: في مواقع الحجوزات، كل عميل يحجز مقعده بدون تضارب مع حجز الآخرين.



3️⃣ التوافق مع القوانين والأنظمة

في مجالات مثل البنوك أو التجارة الإلكترونية، الالتزام بمعايير أمان البيانات شيء ضروري لتجنّب الغرامات والمشاكل القانونية.
مثال: أنظمة الحماية تتطلب ضمان التناسق والعزل لأي عملية، وACID يساعدك تحقق هذا.



4️⃣ تجنّب الكوارث التقنية

تطبيق ACID يقلل احتمال حدوث أخطاء مثل:

اختفاء البيانات.

تعطل النظام بسبب كثرة العمليات.

ظهور أخطاء بسبب تحديث نصف مكتمل.


مثال: إذا النظام انهار فجأة، تضمن خاصية Durability أن البيانات تظل محفوظة وآمنة.



خلاصة الفائدة 🎯

ACID ما هو مجرد نظرية، هو درعك كمهندس برمجيات لتبني أنظمة قوية، آمنة، ومستدامة.
بدونه، أنظمتك ممكن تنهار أمام أول ضغط أو خطأ.

💡 نصيحة شخصية:
لما تكون فاهم هذي المفاهيم، تقدر تناقش أي نظام أو مشروع بثقة. العملاء وأصحاب العمل دايم يحبون المطور اللي يركز على الجودة والأمان.
وشكرا!

حرب البيانات والذكاء الاصطناعي: رؤية منظمة

البيانات هي السلاح الأقوى

في عصر تطور الذكاء الاصطناعي بشكل كبير، كل شيء يتمحور حول البيانات. الذكاء الاصطناعي يعتمد على كميات هائلة من البيانات لتدريب خوارزمياته، مما يجعل البيانات المورد الأهم. إذا فكرت في بناء نظام منافس مثل OpenAI، فالأمر لا يتوقف فقط على الحصول على الخوارزميات بل على امتلاك مخزن بيانات ضخم ومدرب على مدى سنوات طويلة.


---

الصراع بين القوى العظمى

الصين: تعيش في عالم رقمي معزول عن بقية العالم، وتهدف إلى حماية شعبها وخصوصياته من الهيمنة الغربية. إطلاق أدوات مثل DeepSeek ليس حباً في الخدمة المجانية، بل لضمان السيطرة المحلية على البيانات ومنع تدفقها إلى الخارج.

الغرب: يعتمد على شركات مثل OpenAI التي تمتلك مخزوناً ضخماً من البيانات يجمع معلومات مفيدة وضارة عبر السنين.



---

التكنولوجيا والحروب الحديثة

السيطرة الرقمية: امتلاك البيانات أصبح أشبه بامتلاك السلاح النووي في العصر الحديث، ولكن بكلفة أقل وخطورة أعلى. الدول التي تستثمر في جمع وتحليل البيانات يمكنها فرض هيمنتها دون الحاجة إلى تدمير المدن كما حدث في هيروشيما.

الاختراق المستمر: كل فرد الآن مخترق بطريقة ما عبر الهواتف الذكية. الجوال الذي تملكه وتدفع ثمنه بنفسك قد يكون بوابة لعدوك لجمع بياناتك أو التأثير عليك.



---

التوازن بين الفائدة والتكلفة

في إدارة المشاريع الكبرى، يتم دراسة التوازن بين التكلفة والفائدة. استخدام البيانات والذكاء الاصطناعي يتبع نفس المبدأ:

هل الاستثمار في التكنولوجيا يحقق أرباحاً أكبر من التكاليف؟

إذا كانت البيانات قادرة على تحقيق السيطرة أو الهيمنة، فهي تستحق الاستثمار.



---

الأزمات التقنية: المستقبل القادم

مثلما واجه العالم أزمات في النفط والغاز، سيأتي وقت لأزمة تقنية كبيرة. هذه الأزمة قد تكون نتيجة الاعتماد المتزايد على الذكاء الاصطناعي، مما يؤدي إلى تضاعف أرباح الشركات التي تتبناه.


---

التهديدات المستقبلية

الذكاء الاصطناعي كأداة هيمنة: الشركات التي تعتمد على الذكاء الاصطناعي بشكل كلي أو جزئي ستكتسب قوة اقتصادية وسياسية ضخمة.

الهجمات الرقمية: بدلاً من الحروب التقليدية، يمكن استخدام الذكاء الاصطناعي والبيانات كقنابل رقمية لضرب الخصوم بفعالية.



---

الخلاصة

الذكاء الاصطناعي ليس مجرد أداة تطوير، بل أصبح قوة تسيطر على العالم. البيانات هي العامل الأساسي في هذه المعادلة، ومن يسيطر عليها يمتلك مفاتيح المستقبل.

Gpt

حرب البيانات
كيف شف وأنت بتشوف تطور الذكاء الاصطناعي هذا بشكل كبير الموضوع كله يدور حول البيانات لو قلت لي اريد ابني مثلهم حتى ادخل السوق وانافسهم اقلك لا تتعب سأذهب إلى شركة openAI واقلهم اعطوني الخوارزميات هذه بكل بساطة طيب الان امتلكتها عم الحج هل معك مخزن بيانات تدرب عليها له مئات السنين يجمع معلومات عنك منها مفيد وضار وغيرها عنده بنوك بيانات تقلي نعم الان الصينيون يتنافسون وأطلق الان ال deepseek هو مش حب فيك أو خدمه هو صاحبنا خائف على شعبه وخصوصياته يعني تجمع بيانات عن شعبي الصين هي في عالم تماما معزول في النت لها عالمها الان الحرب هي بيانات لو قلت لك ان امتلاكك لنووي هو عبارة عن مشروع ضخم جدا لكن صعب أليس في أدارت المشاريع الان بتدرسها لو التكلفة اكثر من الفائدة الي ستحققها بلاش المشروع ليس هذا فقط الخطورة انه عدوك انت خلقت لك عدو في البيت الغربيون تعلمون من خطأهم عندما رما القنبلة الذرية تقريبا على مدينه هيروشيما أنت دمرت مدينه عن بكرت أبيها ماعد فائده انك تفرض سيطرتك في طرق أخرى تخضع بها أي عدو لو قلت لك ان أي دولة الآن مخترق من أصغر طفل إلى أكبر سن عن طريق الجوال اقدر اصنع قنبلة مؤقته مثلا لو دخلنا أنا وأنت في حرب وصراع على المدى البعيد اقرحك بأقل الخسائر من جيبك أنت من دفع قيمة الجوال أنت مخترق منذ زمن طويل في أزمات صح مثل ازمة غاز أزمة نفط لأبد من أزمة تكنلوجيه تعيد العالم شوي لو قلت لك ان الآن اه ذكاء اصطناعي ومدري ايش يعني أصبح يتحكم بكل العالم بيده في شركات سيتضاعف اربحها بسبب اعتمادة عليه سواء جزء أو كلي فبعد فترة من الزمن أنا عملت لك ضربه بين عيونك لو اريد اقرحك جو لا اقرحك وتفرح الشركة جو
.اعيد كتابتها بشكل منظم ومتسق

تشتغل backend ؟
تستخدم framework مثل لارافل ؟
في تعديل على database ؟

لا تعدل على ملفات المجريشن القديمه... افعل ميجريشن جديد عشان لا تضيع وقت على زميلك.
مثلا في حاله تعديل اسم عمود status الى is_active في جدول اليوزر:

php artisan make:migration rename_status_to_is_active_in_users_table

وتكتب الكود الي بيكون:

Schema::table('users', function (Blueprint $table) {
    $table->renameColumn('status', 'is_active
});

وال down يكون:

Schema::table('users', function (Blueprint $table) {      
    $table->renameColumn('is_active', 'status
});

عشان ال tree حق migrations ما تخرب عليكم + اي تعديل جديد في db ما يضطر فريق العمل يحذف الـ db ويفعل لها migration + seeder من جديد.

#مساعد

+ طبعا للتوضيح

ال migrations هو فقط زي tree للفريمورك عشان تعرف ايش الي تم انشاءة في db وايش الي تعدل

فيعني مش عيب او انها بلاده لو في مشروع وفيبه ملفات migrations كثير


هو اصلا دليل التقدم والتحسن... لانه انت لما تبرمج المشروع وتكتشف مشكله او نقص في db تضيفه
وهكذا...

وهذه الصورة تصف عدد ملفات الـ migrations في مشروع خاص بشركه... تقريبا 317 ملف
يعني لا تفكرو فيها كأسلوب عدد وانه لازم قليل مره (او كثير مره)

كله على حسب المشروع والتعديلات الي حصلت في DB

تطبيق الـ Change Data Capture (CDC) في Pinterest: نهج مبتكر لتحسين الأداء 🚀

الـ Change Data Capture (CDC) هو واحد من أهم الأساليب اللي بتساعد في تتبع التغييرات اللي بتحصل في قواعد البيانات بشكل لحظي. في شركة مثل Pinterest، كانت تقنية CDC حل عبقري ساعدهم في التعامل مع البيانات بشكل أكثر كفاءة وسرعة. خلونا نتكلم عن فكرة CDC بشكل أبسط ولماذا يعتبر من الأساسيات في التعامل مع البيانات.

إيش يعني CDC؟ 🤔

الـ CDC هو مجموعة من الأنماط اللي تتيح لك متابعة التغييرات في قاعدة البيانات، زي الإضافات (inserts) ✨، التحديثات (updates) 🔄، والحذف (deletes) ❌. الفكرة الأساسية في CDC هي إنه يلتقط التغييرات أول بأول في الوقت الفعلي ⏱، وده بيخلي التطبيقات قادرة على التعامل مع التحديثات بسرعة ودقة.

ليه الـ CDC مهم؟ 🤩

1. معالجة البيانات في الوقت الفعلي (Realtime):
من خلال CDC، ممكن النظام يتعامل مع البيانات بشكل فوري، وهو شيء مهم خصوصًا في التطبيقات اللي زي أنظمة الكشف عن الاحتيال 💳 أو محركات التوصية 🔍 اللي تحتاج معلومات حديثة طوال الوقت.


2. تكامل البيانات بين الأنظمة:
CDC بيسهل عملية التكامل بين الأنظمة المختلفة 🌐، يعني البيانات اللي بتتغير في نظام واحد، تقدر توصل لأنظمة تانية بسهولة، حتى لو كانت تستخدم قواعد بيانات مختلفة.


3. تقليل الحمل على الأنظمة المصدرية:
بدل ما يكون عندك حمل كبير من نقل البيانات كاملة، CDC بيكتفي بتتبع التغييرات فقط 📉، مما يعني أقل ضغط على النظام الأساسي وأداء أسرع.


4. التدقيق والامتثال:
مع CDC، تقدر تتابع كل التغييرات وتوثقها بشكل دقيق، وده مهم جدًا في حالات الـ Auditing والتأكد من الالتزام بالقوانين واللوائح 📝.



ليش اختاروا Pinterest CDC بدل من Binary Log Files؟ 🤔

1. التخصيص والمرونة:
CDC بيتيح لك تخصيص التغييرات اللي عايز تتابعها بشكل دقيق. على عكس Binary Log Files اللي بتسجل كل التغييرات، حتى لو مش كلها هتحتاجها.


2. التكامل بين الأنظمة:
CDC بيسمح بمتابعة التغييرات في الأنظمة المختلفة بكل سهولة 🌍، بينما Binary Log Files بتكون موجهة في العادة لنظام واحد.


3. تحسين الأداء:
من خلال CDC، أنت مش محتاج تتابع كل العمليات، بس التغييرات، وده بيقلل الضغط على الأنظمة ويحسن الأداء بشكل عام ⚡.


4. سهولة التكامل:
CDC بتخلي عملية دمج البيانات بين الأنظمة أسهل، وده بيخليها الخيار المثالي في بيئات العمل المتطورة والمليئة بالأنظمة المختلفة 💡.



الخلاصة 📝

Pinterest استخدموا CDC بشكل مبدع علشان يحققوا تحسين كبير في الأداء وتكامل البيانات بين الأنظمة المختلفة. بينما كانت Binary Log Files موجودة في البداية، لكن CDC أثبتت أنها أكثر كفاءة ومرونة في التعامل مع التغييرات في الوقت الفعلي.

بدلاً من القلق بشأن العدد، اسأل نفسي: هل هذه الملفات مرتبة ومُنظمة؟ هل تعكس الحاجة الحقيقية للعمل؟ إذا كانت الإجابة نعم، فأنت على الطريق الصحيح، بغض النظر عن العدد شكرًا لك 🌹

من أكبر التحديات الي ستواجهه في microservices
OpenTelemetry هو إطار عمل مفتوح المصدر يهدف إلى جمع ومراقبة بيانات التتبع (Tracing)، القياسات (Metrics)، وتسجيل الأحداث (Logging) في الأنظمة الموزعة مثل Microservices.

الصراحة في الأنظمة الموزعة التواصل بين الخدمات بيكون معقد، وهنا الصعوبة الحقيقية في تتبع الأخطاء وتحليل الأداء. وهنا يجي دور OpenTelemetry اللي يعطي رؤية كاملة للنظام من خلال:

1. تتبع الطلبات بين الخدمات (Distributed Tracing):
تقدر تتابع الطلب من أول ما يدخل للنظام لين ما ينتهي، وهذا يساعدك تكتشف أي مشاكل أو نقاط ضعف.


2. قياس الأداء (Metrics):
يوفر لك بيانات تفصيلية مثل استهلاك CPU، استخدام الذاكرة، وعدد الطلبات اللي تمر بالنظام.


3. تسجيل الأحداث (Logging):
كل الأحداث اللي تصير داخل النظام يتم تسجيلها لتحليلها لاحقًا.



أهم شيء يعجبني في OpenTelemetry هو إنه:

مرن وقابل للتكامل مع أي أداة: تقدر تربطه مع أدوات مثل Jaeger، Prometheus، أو حتى Grafana.

يدعم لغات كثيرة: مثل C#, Python, Java وغيرها، يعني ما في عذر لو بتشتغل بأي لغة.

بسيط وسهل التوسيع: أي بيانات تحتاج تضيفها، تقدر ببساطة تعملها.


فكرة النظام إنه يعطيك تحكم كامل، يخلّي التحليل والتتبع عملية واضحة، ويضمن لك أداء عالي. إذا كنت بتشتغل على أنظمة موزعة، أنصحك تبدأ تستخدم OpenTelemetry، لأنه فعلاً بيغيّر طريقة مراقبتك للنظام.

من أفضل الميزات لو بتستخدم GraghQL هي عمل loosely coupling بين مبرمج ا ل backend و frontend وهذه من المشاكل الي كان تعاني منها فيسبوك ناهيك عن بقيت الميزات بس هذه الي فعلا أعجبتني

الغامضين هم الأشخاص اللي غالباً ما يحتفظوا بكل شيء لأنفسهم وما يشاركوا مشاعرهم أو أفكارهم بشكل واضح وصريح. لما تجلس معهم، تحس كأن فيه حائط بينك وبينهم، وما يكون فيه أي تفاعل حقيقي.
سمات الأشخاص الغامضين في هذه الحالة:

الصمت الزائد: دائماً يفضلوا الاستماع فقط بدون إبداء رأي أو تعليق.

قلة التفاعل: ما يشاركوا في النقاشات، حتى لو كان الموضوع يخصهم أو مهم.

عدم الوضوح: لما تسألهم سؤال مباشر، تحصل إجابات مختصرة وغالباً ما تكون غامضة أو مبهمة.

انعدام المشاركة: لا يشاركوا أي تجارب شخصية أو أفكار تقدر تتعلم منها أو تتطور من خلالها.

عدم الحماس: يظهر عليهم عدم الاهتمام أو الاكتراث لأي شيء، سواءً عن نفسك أو عن المستقبل.

أثر الغموضيين عليك:

بيخلوك تحس بعدم الراحة أو الحرج.

يقللوا من مستوى الحماس أو الإيجابية في الجلسة.

أحياناً قد تشعر وكأنك تبذل مجهوداً كبيراً لتحريك الحديث أو النقاش.

كيف تتعامل معهم؟

حاول تستفسر بطريقة مهذبة ومباشرة عن وجهات نظرهم.

إذا لاحظت إنهم ما يقدموا أي قيمة إيجابية، فكّر في تقليل الوقت اللي تقضيه معاهم.

ركّز على بناء دائرة اجتماعية من أشخاص يشجعوك ويدعموك بدلاً من استنزاف طاقتك في محاولة فهمهم أو التعامل معهم.

ستواجها بشكل كبير

كوهيجن؟ كابلنج؟ أيش القصة؟
تخيل معي: انت حر مستقل، كل اللي تحتاجه داخل بيتك. أمورك مرتبة، عايش برضا وبانسجام مع نفسك، هذه نسميها Cohesion. 🏡
لكن لو حياتك مربوطة بجارك، كل ما تحتاج حاجة تسأل عليه، وتنتظر يساعدك تحل مشاكلك، هذه نسميها Coupling. 🔗

الدرس؟
خلّي بيتك مكتفّي بخيره (High Cohesion)، وقلل علاقتك بالجيران قدر المستطاع (Weak Coupling)، عشان لو غيرت بيتك، ما تضطر تبني الحارة كلها من جديد. 🚀💡

تطبيق في البرمجة: لو عندك function، خليها مستقلة. كل اللي تحتاجه تمرّره كـ parameters أو يكون داخلها local variables. 🛠️ لو عندك class، ما تعتمد كثير على classes ثانية. اجعل الكلاس يؤدي وظيفة واضحة ومحددة. 🧩 لو عندك system، حاول تقلل الـ dependencies على الأنظمة الأخرى. 🌐 مبدأ الحياة ببساطة:

✨ "You must be high cohesion and loosely coupled!" 💪

أخي المبرمج، خليني أشرح لك العلاقة بين Domain-Driven Design (DDD) وClean Architecture بشكل عبقري ومش ممل، ولو كنت في مقيل مع أصحابك في اليمن، ما بتحتاج غير قهوة مُرّة وهذا الكلام الجميل!
القصة تبدأ من عند التعقيد:
في DDD، قالوا لك إن التعقيد في البرمجيات ينقسم لنوعين:
1️⃣ تعقيد أساسي/طبيعي (Essential Complexity):
هذا التعقيد جاي من طبيعة المجال اللي تشتغل عليه (Domain). يعني مثلاً لو تشتغل على نظام مستشفيات، بيجيك التعقيد من قوانين البزنس، مثل إدارة المرضى، أوقات الأطباء، والمواعيد... يعني وجع راس طبيعي يخص مجال العمل نفسه.
2️⃣ تعقيد صناعي/عرضي (Accidental Complexity):
هذا النوع ماله دخل بالبزنس. هو نتيجة اختيارك لتصميم غير جيد أو استخدام تقنيات معقدة بلا داعي. يعني أنت اللي "تطبخ التعقيد" بيدك في الكود 😅.
💡 DDD قالت لك نصيحة ذهبية:
"افصل بين التعقيدين دول يا بطل. لا تخلي التفاصيل التقنية (اللي تتغير) تلخبط فهمك للبزنس (اللي ثابت نسبياً)."
المشكلة: كيف ننفذ الفكرة؟
هنا DDD أعطتنا الفكرة، لكنها ما شرحت "الطبخة". فقام المطورين وقالوا:
1️⃣ خلينا نستخدم الـ Layered Architecture، بس بنقسم الطبقات بشكل أوضح كالتالي:
Domain: فيه القواعد والقوانين الخاصة بالبزنس.
Infrastructure: يتعامل مع قواعد البيانات أو الأمور التقنية المتغيرة.
Service: هو الوسيط بين البزنس والتقنية.
Presentation: واجهة المستخدم.
2️⃣ بعدها ظهرت تصاميم معمارية زي:
Hexagonal Architecture (الشكل السداسي).
Onion Architecture (شكل البصل).
وبعدين دخل العم بوب مارتن (Uncle Bob) بالساحة وقال:
"اسمعوا يا جماعة، أنا عندي اسم أفضل ورؤية أوضح: Clean Architecture."
وترك بصمته الذهبية، لما قال:
"لما تنظر للتطبيق، لازم يكون البزنس واضح وضوح الشمس. البنية التقنية الداخلية؟ خليها وراء الكواليس!"
التقاء الأفكار
كل هذه المعماريات تشترك في فكرتين رئيسيتين:
1️⃣ فصل البزنس عن التفاصيل التقنية:
وهذا بالضبط اللي نادت به DDD.
2️⃣ استخدام الـ Dependency Injection (DI):
كل شيء في طبقة الـ Domain يعتمد على واجهات (Interfaces)، والتفاصيل التقنية (مثل قواعد البيانات) يتم تطبيقها في طبقة الـ Infrastructure. والربط يتم باستخدام DI.
يعني لو بكرة حبيت تغيّر قاعدة البيانات أو تضيف تقنية جديدة، التطبيق بيظل سليم بدون ما ينكسر.
💡 الخلاصة:
DDD عطتك الفكرة، وClean Architecture نفذتها بشكل عبقري. النتيجة؟
بدل ما تغرق في "تعقيد صناعي"، صار البزنس واضح والبنية التقنية مرنة.
تخيل المشهد:
لا بصل يحرقك ولا سداسي يدوّخك، كل شيء مرتب وحلو، وكأنك تشرب قهوتك المرة في قمة جبل!
وآختمها بالنكتة:
اليوم مدرس العلوم قال:
"اللي ما يعرف عناصر الجدول الدوري ما يكلمنيش خالص."
وأنا أقولك:
"اللي ما يعرف DDD، ما يكلمنيش أصلاً!" 😅

وعاد في Architecture  يستخدم بكثره بذات في microservices  يسمى  vertical  slice Architecture    مرن جدا ومناسب ل في بعض micro خالي بالك ليست انك كيف تنظم الملفات لا غلط فادح موضوع موضوع فصل وتسهيل لعمليات الاختبارات وغيرها انتبه ان اعتقادك فقط كيف تنظم الملفات وأن المعماريات هذه هي كيف تنظم الملفات انتبه

عم الحج معي

تمام يا حبيب أخوك، خلينا نوضح نقطة مهمة جدًا عن Vertical Slice Architecture، خصوصًا في Microservices، وكيف إنها مش مجرد "طريقة لتنظيم الملفات". الموضوع أعمق من كذا بكثير. لو كنت فاكر إن المعماريات كلها بس مجرد تنظيم ملفات، فإنت بتختصر فكرة كبيرة جدًا بشكل خاطئ. 😅
إيش هي Vertical Slice Architecture؟
Vertical Slice Architecture تركّز على تقسيم التطبيق بناءً على الميزات أو الوظائف (Features) بدلًا من الطبقات التقليدية.
كل "شريحة عمودية" (Vertical Slice) تشمل كل ما تحتاجه لتنفيذ ميزة معينة، من البداية (API) للنهاية (قاعدة البيانات).
بمعنى آخر:
بدل ما تقول "عندي طبقة للعرض، طبقة للمنطق، وطبقة للبيانات"، تقول:
"عندي شريحة عمودية اسمها إضافة مستخدم، وشريحة أخرى اسمها إدارة الطلبات".
ليه Vertical Slice Architecture مرنة ومثالية للـ Microservices؟
فصل المسؤوليات بشكل كامل:
كل شريحة مستقلة بنفسها وتتعامل مع ميزة واحدة. هذا يجعل الكود خالي من التداخل.
سهولة الاختبار (Testing):
كل شريحة يمكن اختبارها كوحدة منفصلة (Unit Testing أو Integration Testing) دون التأثير على بقية التطبيق.
تحسين القابلية للتوسع (Scalability):
لو احتجت توسّع ميزة معينة، تشتغل فقط على شريحتها بدون لمس باقي النظام.
تنظيم يعتمد على الـ Domain:
بدل ما تفكر في كيف أنظم الملفات؟، تفكر في كيف أنظم الميزات بناءً على طبيعة التطبيق؟.
توافق تام مع DDD:
لأنه يعكس الفكرة الأساسية في DDD بفصل التعقيد الأساسي (Essential Complexity) عن التعقيد الصناعي (Accidental Complexity).
مغالطة تنظيم الملفات
خليني أوضحها بشيء من التفصيل:
Vertical Slice Architecture مش مجرد طريقة لتنظيم الملفات.
لو فكرت فيها كأنها "فين أحط الفولدر ده؟"، فأنت ما فهمت الفكرة.
هي بالأصح منهجية كاملة لتصميم التطبيق بحيث كل شريحة تمثل مسار مستقل من العمل (Workflow).
الملفات قد تكون جزء صغير جدًا من التنفيذ، لكن الجوهر الحقيقي هو الفصل بين الشرائح بناءً على الوظائف والتدفق الوظيفي (Workflow).
كيف تنفذ Vertical Slice Architecture؟
كل شريحة هي وحدة متكاملة:
تحتوي على:
Endpoint/API أو Command/Query لتفعيلها.
منطق العمل (Business Logic).
وصول البيانات (Data Access).
كل هذا مدمج مع بعضه لشريحة معينة.
استخدام تقنيات CQRS:
عادةً يتم استخدام CQRS (Command Query Responsibility Segregation) مع Vertical Slice، حيث تكون الأوامر والاستعلامات مفصولة لكل شريحة.
مثال بسيط:
لو عندك ميزة اسمها "إضافة مستخدم"، الشريحة العمودية قد تحتوي:
ملف Command: مسؤول عن تنفيذ العملية.
ملف Handler: يحتوي منطق العمل الخاص بالعملية.
ملف Data Access: يتعامل مع قاعدة البيانات.
توضيح بأمثلة بسيطة
الطريقة التقليدية (Layered Architecture):
Controllers/ UserController.cs Services/ UserService.cs Repositories/ UserRepository.cs
Vertical Slice Architecture:
Features/ AddUser/ AddUserCommand.cs AddUserHandler.cs AddUserValidator.cs
الخلاصة
Vertical Slice Architecture مبنية على فصل المسؤوليات وتبسيط التطبيق من خلال تقسيمه بناءً على الوظائف بدلًا من الطبقات.
فهمك لهذا النمط كـ "طريقة لتنظيم الملفات" يعتبر خطأ فادح، لأن المعمارية تهدف لجعل الكود أكثر قابلية للتطوير، الفهم، والاختبار، وليس فقط ترتيب الملفات في الفولدرات.
ركز دائمًا على المفهوم الأساسي:

"كيف أفصل الوظائف في التطبيق بشكل يسهل العمل عليها مستقلًا عن بقية الأجزاء؟"

ختامًا، إذا كنت في مقيل مع أصحابك، قل لهم:
"لو ما تعرفش Vertical Slice Architecture، خلّيك في الكبسة وما تدخل في النقاش!" 😅