يعني شنو معمارية ؟!

في بداية تعلم الـSoftware Architecture، كنت أتعامل مع كلمات مثل Domain وArchitecture وBoundaries وInterfaces وكأنها مصطلحات معقدة.

لكن لما تفككها، تجد أنها في الأساس طريقة منظمة للتفكير في النظام.

الـDomain هو: ما الذي يحاول البرنامج حله؟ وما هي قواعد الـBusiness؟

مثلًا في متجر إلكتروني:

المستخدم ينشئ طلبًا، الطلب يحتوي منتجات، الدفع قد ينجح أو يفشل، والطلب لا يمكن إلغاؤه بعد الشحن.

هذه هي الـBusiness Rules.

أما الـArchitecture فهي: كيف أنظم أجزاء البرنامج؟ ومن يعتمد على من؟ وأين أضع كل مسؤولية؟

مثلًا:

Users

Orders

Payments

Inventory

ليس معنى وجود علاقة بينها أنها يجب أن تكون كلها متشابكة في الكود.

الـBoundary هو الخط الذي يحدد مسؤولية كل جزء، وما الذي يُسمح له بالتعامل معه من الخارج.

مثلًا Orders يحتاج أن يعرف هل الدفع نجح، لكنه لا يحتاج أن يعرف تفاصيل Stripe أو كيف تتصل بوابة الدفع بالبنك.

وهنا تظهر أهمية الـInterfaces.

بدل:

Orders → Stripe SDK

نستطيع أن نجعلها:

Orders → PaymentGateway → Stripe

وبذلك نستطيع تغيير Stripe أو إضافة وسيلة دفع أخرى دون إعادة بناء منطق الطلبات.

أما Architectural Principles فهي القواعد التي نستخدمها للحفاظ على التصميم، مثل:

Low Coupling

High Cohesion

Separation of Concerns

Dependency Inversion

والـTechnical Constraints هي القيود التي تأتي من الواقع، مثل:

استخدام PostgreSQL

العمل على AWS

دعم 100,000 request/minute

زمن استجابة أقل من 200ms

عدم كسر API موجودة

لكن السؤال الأهم:

كيف أعرف أن الـArchitecture جيدة؟

ليس هناك رقم سحري.

اسأل:

ماذا يحدث إذا غيرت Stripe؟

كم جزءًا سأعدل؟

ماذا يحدث إذا تغيرت قواعد الطلبات؟

هل سأعدل Orders فقط أم نصف النظام؟

هل أستطيع اختبار الـBusiness Logic بدون تشغيل Database وRedis وHTTP وكل الخدمات؟

هل أستطيع زيادة عدد Servers لجزء معين بدون أن أكسر باقي النظام؟

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

وأعتقد أن هذا أيضًا يغير طريقة استخدامنا للـAI في البرمجة.

ليس الهدف أن نقول للـAI:

"ابنِ لي تطبيقًا كاملًا."

الأفضل أن نعطيه:

Business Requirements

Domain

Boundaries

Architecture Principles

Technical Constraints

ثم نستخدمه في تنفيذ التفاصيل، وكتابة الاختبارات، والـRefactoring، ومراجعة التصميم.

لأن المشكلة اليوم لم تعد فقط:

"هل أستطيع كتابة الكود؟"

بل أصبحت:

"هل أستطيع اتخاذ القرار الصحيح بشأن النظام الذي يجب أن أبنيه؟"

وهذه برأيي من أهم المهارات التي يجب أن يطورها أي Software Engineer مع ازدياد الاعتماد على الذكاء الاصطناعي.