تعالوا نتكلم "صنعة باك-إند" بعيداً عن خناقات الفريموركس والمقارنات السطحية.
لو سألت أي مطور باك-إند لسه بيبدأ: "إنت بتنظم كودك إزاي؟"، غالباً الإجابة هتكون: "بعمل فولدر للـ Controllers وفولدر للـ Models.. إلخ". لكن لما الـ Scale بيكبر، والـ Requests بتدخل في ملايين، والبزنس شروطه بتتغير كل أسبوع، تنظيم الفولدرات ده مش هيحيلك مشكلة. هنا بقى بنبدأ نتكلم Software Architecture Styles.
الـ Architecture مش رفاهية، دي الطريقة اللي السيستم بتاعك بيتنفس بيها. تعالوا نفصص الـ 10 أنواع الأشهر في عالم الـ Back-end والـ System Design عشان ننقل تفكيرنا من مجرد "كاتب كود" لـ "مهندس أنظمة":
1. Monolithic Architecture (الكل في واحد)
ده البداية الطبيعية لأي مشروع في الدنيا. الكود كله عبارة عن كتلة واحدة (Single Unit)، الـ UI والـ Business Logic والـ Database Access كله عايش في نفس الـ Repository ويدخل له Deploy مع بعضه.
اللقطة بتاعته: سريع جداً في التطوير والـ Testing في الأول، والـ Deploy بتاعه بيبقى ملف واحد بترفع وخلاص.
الواقع الصادم: لما المشروع بيكبر والفريق يوسع، الكود بيتحول لـ "طبق مكرونة اسباجيتي". تعديل بسيط في سيرفيس الحسابات ممكن يوقع سيرفيس المخازن، والـ Build بياخد سنين.
2. Microservices Architecture (الخدمات المصغرة)
عكس الـ Monolithic تماماً. بنقسم السيستم لخدمات صغيرة ومستقلة تماماً عن بعضها (مثلاً: User Service, Order Service, Payment Service). كل خدمة ليها قاعدة بياناتها الخاصة، وبيتكلموا مع بعض من خلال APIs أو Message Brokers عبر الـ API Gateway.
اللقطة بتاعته: بيخلي كل فريق يمسك سيرفيس يطورها ويعمل لها Deploy لوحدها دون الاعتماد على الباقيين، ويديك Scalability مرعب.
الواقع الصادم: "مبيدخلش بيت إلا لما يخرب ميزانيته" لو اتعمل بدري. الـ Network Overhead بيبقى عالي، والـ Debugging بيبقى كابوس، وإدارة اتساق البيانات (Data Consistency) بين الداتا بيز المختلفة بتبقى صداع مزمن.
3. Hexagonal Architecture (السداسي)
الفكرة هنا إن قلب الأبليكيشن (Business Logic) يكون معزول تماماً في المنتصف، وما يعرفش أي حاجة عن العالم الخارجي ولا يتأثر بيه.
اللقطة بتاعته: بنعمل حاجة اسمها Ports (Interfaces) وAdapters. لو حبيت تغير قاعدة البيانات من MySQL لـ MongoDB، أو تغير سيرفيس بعت الإيميلات، إنت مش بتلمس قلب الأبليكيشن؛ إنت بس بتغير الـ Adapter على الأطراف.
الواقع العملي: ممتع جداً في الـ Unit Testing لأنك بتعمل Mock لأي حاجة خارجية بسهولة، وبيخلي كودك مرن ولين للمستقبل.
4. Event-Driven Architecture (المعماري المعتمد على الأحداث)
هنا السيرفرات والمكونات مابتكلمش بعضها بشكل مباشر (Synchronous)، لأ.. السيستم بيمشي بمبدأ "إرمي الكلمة واجري". حتة في السيستم تعمل أكشن، فتذيع (Publish) إيفينت: "يا جماعة، الـ Order اتدفع!".
اللقطة بتاعته: بيبقى فيه وسيط في النص (Event Bus زي Kafka أو RabbitMQ). أي سيرفيس تانية مهتمة بالحدث ده (Consumers) بتلقطه وتنفذ شغلها في الخلفية (Asynchronously) زي سيرفيس الفواتير أو الشحن.
الواقع العملي: بيخلي السيستم Decoupled تماماً وسريع في الاستجابة (Highly Responsive) لأن الـ User مش بيفضل مستني كل السيرفيسز دي تخلص في نفس الريكويست.
5. Layered Architecture / N-Tier (النظام الطبقي)
ده "الأب الروحي" لتنظيم الكود اللي أغلبنا اتربى عليه. بنقسم الكود لطبقات أفقية فوق بعضها (Presentation → Application → Business → Data Access). التوجيه دايماً أحادي من فوق لتحت؛ كل طبقة تنده اللي تحتها بس.
اللقطة بتاعته: منظم جداً، سهل الفهم، ومكتوب في الـ DNA بتاع فريموركس كتير.
الواقع الصادم: مع الوقت بيتحول لـ "Database-Centric". كود البزنس بيبقى مجبور ومفصل على شكل جداول الداتا بيز، وأي تغيير تحت بيسمع ويكسر في كل الطبقات اللي فوق.
6. Clean Architecture (العمارة النظيفة)
دي اللي صاغها Uncle Bob وهي قريبة من الـ Hexagonal. الكود عبارة عن دوائر جوة بعضها، وفي المركز (الداخل) بيقعد البزنس الثابت (Entities & Use Cases)، وعلى الأطراف برة بتقعد التفاصيل (Frameworks, DB, UI).
اللقطة بتاعته: القاعدة الذهبية: "الداخل لا يعرف شيئاً عن الخارج". الـ Use Case مستحيل يعرف إنت شغال بـ Laravel أو Express، الفريمورك مجرد أداة خارجية (Detail).
الواقع العملي: بتديك كود يعيش 10 سنين قدام وتقدر تقلب التكنولوجيا المستخدمة في أي وقت، بس عيبها إنها محتاجة Boilerplate وكتابة كود كتير في أول المشروع.
7. CQRS (فصل القراءة عن الكتابة)
اختصار لـ Command Query Responsibility Segregation. هنا إحنا بنفصل كود الـ Write (تعديل البيانات/Commands) تماماً عن كود الـ Read (جلب البيانات/Queries).
اللقطة بتاعته: في الأنظمة الضخمة، الـ Queries المحتاجة تجميعة (Join) من جداول كتير بتبهدل الأداء. فبنعمل موديل وقاعدة بيانات سريعة جداً للقراءة بس (زي Elasticsearch أو Redis كـ Read Model) وباقي العمليات المعقدة على الـ Write Model، ويحصل بينهم مزامنة في الخلفية.
الواقع العملي: بيطير بالأداء في المواقع اللي فيها قراءة مرعبة مقارنة بالكتابة (زي منصات الأخبار أو السوشيال ميديا).
8. Serverless Architecture (المعماري بدون سيرفر)
إنت مش بتأجر سيرفر كامل شغال 24 ساعة وبتدفع تمنه وبتعمل له Manage. إنت بتقسم الأبليكيشن لوظائف صغيرة (Functions) وترفعها على السحابة (زي AWS Lambda).
اللقطة بتاعته: الكود بيصحى ويشتغل في الـ Cloud "فقط" لما ريكويست يجي، ويموت فوراً بعد ما يخلص. محاسبتك المادية بتكون بالـملي ثانية اللي الكود اشتغلها (Pay-per-use).
الواقع الصادم: موفر جداً للـ Workloads غير المنتظمة، بس مشكلته في الـ Cold Start وصعب جداً في الـ Vendor Lock-in والـ Debugging محلياً.
9. Pipeline Architecture (الماسورة والفلاتر)
الداتا بتدخل من ناحية، وتعدي على مراحل متتالية ورا بعض (Sequential Stages). كل مرحلة (Filter) بتاخد المخرج بتاع اللي قبلها، تعمل عليه عملية معالجة أو تحويل، وتسلمه للي بعدها (Process → Transform → Load).
اللقطة بتاعته: ده العصب الأساسي لعمليات الـ ETL (تحليل ونقل البيانات الضخمة) والـ Data Streaming.
الواقع العملي: ممتاز في تتبع الداتا ومعالجتها على خطوات منفصلة تماماً، شبه فكرة الـ Middleware في الـ Web Requests بس على مستوى البيانات نفسها.
10. Space-Based Architecture (الاعتماد على الذاكرة المشتركة)
ليفل الوحش في الـ Concurrency والـ Scalability. لما يكون عندك فجأة ملايين الـ Requests في نفس الثانية (حجز تذاكر، بورصة، Black Friday) والداتا بيز ترفع الراية البيضاء وتوقع السيستم.
اللقطة بتاعته: إحنا بنقفل باب قاعدة البيانات خالص وقت الضغط! الأبليكيشن بيشيل الداتا كلها ويوزعها جوة الـ RAM (In-Memory Data Grid). الـ Processing كله بيحصل في الذاكرة في ميكرو-ثانية، وفي الخلفية بيبقى فيه سيرفيس (Data Pumps) بتاخد الداتا دي على مهلها تنزلها للـ DB الحقيقية.
الواقع العملي: الـ Database لو تقلت، المستخدم برة مش هيحس بأي بطء لأنه شغال مع الـ RAM السريعة جداً. ستايل معقد وغالي بس منقذ للأرواح في الـ Traffic المرعب.
الملخص اللي تطلع بيه كـ Back-end Developer:
مفيش Architecture اسمها "الأفضل" مطلقاً. الشطارة والخبرة الحقيقية مش إنك تروح تعمل Over-engineering وتطير ورا الـ Buzzwords؛ الشطارة إنك تختار الـ Architecture اللي تناسب حجم البزنس، الميزانية، وطبيعة الـ Traffic بتاعك.
Comments
Post a Comment