مساعد المخطط المعماري
درس 11 من 12
11مساعد المخطط المعماري
الصورة الكبيرةالبنية قرارات يصعب تغييرها لاحقًا: أين تُخزَّن البيانات، كيف تتواصل الأجزاء، ماذا يحدث عند العطل. المساعد يسرّع استكشاف الخيارات، لكن القرار يبنى على أرقامك أنت.
ماذا تشاهد في الرسم: من المتطلبات إلى قرار مكتوب. الأسئلة قبل التصميم توفّر أغلب الأخطاء.
خارطة هذا الجزء
المفاهيم بالترتيب، اضغط أيًّا منها للقفز إليه:
طريقان إلى نفس الفكرة
قبل بناء بيت يسألك المهندس: كم شخصًا سيسكن؟ هل ستضيف دورًا لاحقًا؟ ما الميزانية؟ لو بنى دون سؤال قد يعطيك قصرًا وأنت تحتاج شقة. المساعد كذلك: اجعله يسألك أولًا.
ابدأ بالمتطلبات غير الوظيفية بأرقام: المستخدمون المتزامنون، الطلبات في الثانية، حجم البيانات ونموها، زمن الاستجابة المقبول (p95)، الإتاحة المطلوبة، والميزانية والفريق. اطلب من النموذج أسئلة توضيح أولًا، ثم خيارين على الأقل (مثلًا monolith معياري مقابل خدمات) مع مقايضات صريحة، ثم مخطط C4 مستوى الحاويات بصيغة Mermaid، ثم ADR بصيغة: السياق، القرار، البدائل، العواقب. احذر من «تضخيم المقاس»: النماذج تميل لاقتراح Kafka وKubernetes لمشروع يكفيه خادم وقاعدة بيانات.
قبل أن تبدأ
🗄️قواعد البيانات وواجهات API
تعرف SQL وREST.
📐مصمّم الواجهات
الدرس 8 من هذا المسار: التصميم قبل الكود.
الفكرة الجوهرية
1اجعله يسأل أولًا
أول طلب لا يطلب تصميمًا، بل أسئلة:
I am designing the backend for a café ordering app. Before proposing anything, ask me up to 8 questions about load, data, latency, availability, budget and team that would change the design. Do not propose an architecture yet.
2خياران ومقايضات
اطلب خيارين على الأقل في جدول: التعقيد، الكلفة، سهولة النشر، نقطة الفشل، ومتى يصبح كل خيار خاطئًا. خيار واحد يعني أنك لم ترَ البدائل.
3المخطط وسجل القرار
اطلب المخطط نصًا (Mermaid) ليُحفظ في المستودع ويُراجع كالكود، ثم ADR قصيرًا:
flowchart LR app[Mobile app] --> api[API server] api --> db[(PostgreSQL)] api --> cache[(Redis)] api --> pay[Payment provider] # ADR 001: one API server with PostgreSQL Context: 300 orders at peak, 2 developers, budget for one small server. Decision: a modular monolith on one server, PostgreSQL, Redis for the menu cache. Alternatives: services + queue (rejected: operational cost for a team of two). Consequences: simple to deploy; revisit if peak passes 50 orders/second.
مثال محلول
المسألة: المساعد اقترح خمس خدمات مصغّرة وKafka لتطبيق حجوزات عيادة. الأسئلة: كم حجزًا يوميًا؟ 200. كم مطوّرًا؟ واحد. إعادة الطلب: «ما أبسط بنية لهذه الأرقام؟». النتيجة: خادم واحد وPostgreSQL ومهمة مجدولة للتذكيرات، وADR يذكر متى نعيد النظر (10 أضعاف الحجوزات).
خرافة مقابل حقيقة
| الخرافة | الحقيقة |
|---|---|
| البنية الأفضل هي الأحدث. | الأفضل هي الأبسط التي تحقق أرقامك ويستطيع فريقك على تشغيلها. |
| المساعد يعرف حجم مشروعك. | لا يعرف إلا ما تخبره به، فيفترض الحالة العامة. |
اختبر فهمك
ما أول ما تطلبه من المساعد عند تصميم بنية؟
الأسئلة تكشف الأرقام والقيود التي تغيّر التصميم.
ما الذي يحويه ADR؟
يحفظ لماذا اتخذ القرار، لا ماذا فقط.
لماذا تطلب المخطط بصيغة Mermaid؟
المخطط النصي يتغيّر مع الكود في نفس طلب الدمج.
بطاقات مراجعة سريعة
تحقق من فهمك
ما علامة أن المساعد ضخّم الحل؟
مكوّنات تشغيلية (وسيط، منسّق حاويات) لا تبررها أرقام الحمل أو الفريق.
متى تعيد النظر في القرار؟
عند العتبة المكتوبة في عواقب ADR، مثل تضاعف الحمل عشر مرات.
لماذا خياران على الأقل؟
لترى المقايضات، فخيار واحد يخفي ما تتنازل عنه.