𝗪𝗵𝘆 𝗜 𝗦𝘁𝗼𝗽𝗽𝗲𝗱 𝗪𝗿𝗶𝘁𝗶𝗻𝗴 𝗖𝗼𝗱𝗲 𝗮𝗻𝗱 𝗕𝗲𝗴𝗮𝗻 𝗗𝗲𝘀𝗶𝗴𝗻𝗶𝗻𝗴

كنت أعتقد أن تطوير البرمجيات يعني كتابة الميزات فحسب. كنت أظن أن وظيفتي تقتصر على إنشاء الكيانات (entities)، وبناء المتحكمات (controllers)، وربط قواعد البيانات.

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

يجب عليك اتخاذ قرار بشأن المعمارية (architecture). يجب أن تسأل لماذا هي مناسبة، وما تكلفتها، وما هي المخاطر التي تعالجها.

إليكم أهم الدروس التي تعلمتها:

• يجب أن تتناسب المعمارية مع مرحلة المنتج. من المغري استخدام الخدمات المصغرة (microservices)، وKubernetes، وطوابير الأحداث (event queues) المعقدة على الفور. بالنسبة لمشروعنا، اخترنا معمارية طبقية (layered architecture) في عملية واحدة (single process). سمح لنا ذلك بفصل المسؤوليات دون عناء التعامل مع الأنظمة الموزعة (distributed systems). البساطة غالباً ما تكون الخيار الأفضل في البداية.

• بعض القرارات تكون رخيصة الآن ولكنها مكلفة لاحقاً. لقد أضفنا TenantId إلى نموذج البيانات الخاص بنا منذ اليوم الأول. ورغم أنه لم يكن لدينا سوى عميل واحد، إلا أن هذا جعل الانتقال المستقبلي إلى نموذج SaaS أمراً سهلاً. إذا انتظرت طويلاً لإضافة خاصية تعدد المستأجرين (multi-tenancy)، فستصبح عملية الهجرة (migration) كابوساً.

• التصميم يمنع الوصول إلى طرق مسدودة مستقبلاً. البرمجة تحل مشكلة فورية، أما التصميم فيحل المشكلة دون إغلاق الأبواب أمام المستقبل. لقد استخدمنا الحاويات (containers) في وقت مبكر لتسهيل الانتقال إلى بنية تحتية مختلفة، واستخدمنا الواجهات (interfaces) لجعل عملية تبديل المزودين بسيطة.

• التغييرات في الأعمال تقود التغييرات التقنية. ينتقل النظام إلى الخدمات المصغرة (microservices) لأن العمل يتوسع. تطبيق عيادة واحدة يتحول إلى منصة SaaS لمئات العيادات. هذا التحول يغير طريقة تعاملك مع الفواتير، والاشتراكات، والتوسع (scaling).

• الموثوقية تتطلب أنماطاً ذكية. انتقلنا من الاستدعاءات المتزامنة (synchronous calls) إلى المعمارية القائمة على الأحداث (event-driven architecture). في النظام الطبي، لا ينبغي لخدمة إشعارات بطيئة أن تتسبب في تعطل حجز المواعيد. استخدمنا نمط الـ Outbox لضمان بقاء البيانات آمنة حتى في حالة فشل وسيط الرسائل (message broker).

• يجب أن تتناسب الأنماط مع مجال العمل (domain). لا تستخدم الأنماط بشكل أعمى. التشخيص الطبي يتطلب اتساقاً قوياً (strong consistency)، ولا يمكنك الاعتماد على الاتساق النهائي (eventual consistency) من أجل سلامة المرضى. لا تستخدم التخزين المؤقت (cache) للبيانات السريرية الحساسة إذا كان ذلك سيؤدي إلى كسر سجل التدقيق (audit trail) الخاص بك.

• الـ DevOps ليس مجرد فكرة لاحقة. النشر (deployment)، وفحوصات الحالة (health checks)، وخطوط الإنتاج (pipelines) هي جزء من التصميم الأولي. يجب عليك تقدير التكاليف واختيار المكونات التي تخدم احتياجاتك بالفعل.

الفرق بين المبرمج والمصمم يكمن في "لماذا".

يسأل المبرمج: "كيف أجعل هذا يعمل؟" يسأل المصمم: "لماذا يُعد هذا هو الحل الأمثل لهذه المشكلة تحديداً؟"

المصدر: https://dev.to/santiagobrahim/lo-que-aprendi-cuando-deje-de-pensar-solo-en-codigo-y-empece-a-pensar-en-arquitectura-4fnm