أول تغذية راجعة وتقييم من أحد الطلاب الذي قمت بتدريسهم مقرر التسويق بالمحتوى

1 -الإيجابيات:
طريقة شرحك رائعه واستفدت من المقرر كثير بالذات لما نسوي تطبيق عملي والمشروع بنهاية المقرر كان شيء إيجابي لصالحنا عشان نطبق كل اللي تعلمناه واستفدت منه كثيييير وفي اسلوبك لما تتعامل مع طلابك بطريقه عادية بدون رسميات او كمهندس صارم كما ان تفهمك وتركك مجال للمشاركه للجميع كان شيء يتيح لنا الفرصه لتبادل الأفكار.

2 -السلبيات:
في البداية كنت ماأتأقلم مع محاضراتك لكن بعدين تأقلمت وفهمت المقرر.

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

4 -اهم شيء خرجت فيه من التجربة:
اعتقد انه اهم شيء هو المواصله والتعلم المستمر.


"واخيراً شكراً لجهودك معنا وتفهمك لنا وكان مقرر ممتاز اخذناه معك"

عرض تقديمي شرح كيفية عمل نظام ذكي لادارة شكاوى العملاء عن طريق سير عمل N8N

#016 — Software Architecture | معمارية البرمجيات

قبل أن تبدأ في كتابة التفاصيل الصغيرة داخل النظام، هناك سؤال أهم:
كيف سيبدو النظام كاملًا من الأعلى؟
هنا تأتي Software Architecture — معمارية البرمجيات.
المعمارية لا تهتم فقط بالـClasses أو Methods، بل تحدد الصورة الكبرى للنظام:
كيف نقسمه إلى مكونات؟
كيف تتواصل هذه المكونات؟
أين تُخزن البيانات؟
كيف سنتعامل مع الخدمات الخارجية؟
وكيف نجعل النظام قادرًا على التوسع، وآمنًا، ومستقرًا؟

ببساطة:
Architecture = Big Picture
Design = Details

فمثلًا:
Client → API Gateway → Services → Database
هذا قرار معماري.
أما تحديد:
OrderService
createOrder()
cancelOrder()
getOrder()

فهذه تفاصيل أقرب إلى Software Design.
لكن المعمارية لا تعتمد فقط على الوظائف التي يقدمها النظام.
قد تقول المتطلبات
يجب أن يستطيع المستخدم إنشاء طلب.
لكن ماذا لو كان النظام سيخدم مئات الآلاف من المستخدمين؟
ماذا لو تعطل Server؟
ماذا لو توقفت Payment Gateway؟
ماذا لو كان فقدان عملية دفع واحدة غير مقبول؟
هنا تدخل Quality Attributes:

Scalability — قابلية التوسع
Availability — التوفر
Performance — الأداء
Security — الأمان
Reliability — الموثوقية
Maintainability — قابلية الصيانة
وهذه المتطلبات قد تغيّر Architecture النظام بالكامل.
ومن أكثر القرارات التي يواجهها المطورون:
Monolith أم Microservices؟

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

Microservices
ليست دائمًا أفضل.
لأنها تضيف تحديات في:
التواصل بين الخدمات، إدارة البيانات الموزعة، المراقبة، الاختبارات، النشر، والتعامل مع الأعطال.
لذلك لا تختَر Architecture لأنها "رائجة" او شائعة.
اخترها لأنها تحل مشكلة حقيقية في مشروعك
المعادلة الأهم:
Requirements + Constraints + Trade-offs → Architecture
ولهذا:
Good Architecture ≠ More Services
بل:
Good Architecture =
Right Decisions for the Context
المهندس الجيد لا يبحث عن أعقد Architecture، بل عن أبسط Architecture تستطيع تحقيق متطلبات النظام اليوم، وتسمح له بالتطور غدًا دون أن تتحول إلى عبء على الفريق.
Think Big → Decide Carefully → Design Clearly → Then Code

سؤال للنقاش:
لو كنت ستبدأ متجرًا إلكترونيًا جديدًا مع فريق صغير، هل ستختار Monolith أم Microservices؟ ولماذا؟

التالي في السلسلة:
#017 — Architectural Styles
Monolith، Layered، Microservices، Event-Driven… وما الفرق بينها ومتى نستخدم كل أسلوب؟
م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #SoftwareArchitecture #Architecture #SystemDesign #SoftwareDesign #Monolith #Microservices #Scalability #BackendDevelopment #SystemArchitecture #SoftwareDevelopment #SoftwareEngineer #هندسة_البرمجيات #معمارية_البرمجيات #تصميم_الأنظمة #تطوير_البرمجيات