الـ Technical Analysis بالنسبة لي مش meeting بنقعد فيها نقرر هنستخدم Node ولا Python، وAWS ولا Azure، ونطلع مبسوطين إننا اختارنا الstack دي تقريبًا آخر حاجة المفروض نتكلم فيها كنت أنا لسه بقول اني من الناس اللي بتحب تدخل الـ meeting بورق أبيض وmarkers وflip chart، ونبدأ نفكك السيستم حتة حتة لحد ما نعرف هو بيعمل إيه فعلًا، بيتعامل مع مين، والـ data بتتحرك جواه إزاي لأن قبل ما تختار التكنولوجيا، لازم تفهم العالم اللي التكنولوجيا دي المفروض تخدمه دي الطريقة اللي بتبعها أنا عادة ببدأ من الـ personas مين بيدخل السيستم؟ مين بيتفاعل مع مين؟ إيه الـ touch points؟ إيه الـ objects الأساسية في الـ domain؟ وإيه اللغة اللي الـ business بيستخدمها؟ بنرسم حاجة قريبة جدًا من طريقة التفكير في Domain-Driven Design بعد كدة في خطوة مهمة اسمها system boundaries فين حدود السيستم؟ إيه اللي إحنا مسؤولين عنه وإيه اللي بره حدودنا؟ وبعدين ندخل في الطبقة اللي عادة الناس بتحب تقفز لها من أول 10 دقايق الـ modules والـ utilities الأساسية و الـ Data الـ data بتبدأ من فين؟ بتروح فين؟ مين بيملكها؟ مين مسموح له يشوفها؟ هتتخزن قد إيه؟ هتتحرك إزاي؟ إيه اللي محتاج relational database وإيه اللي لأ؟ هل عندنا ETL pipelines؟ Data lake؟ Analytics layer؟ وبنبص على الـ data وهي at rest وهي in motion بنبدأ نتكلم في authentication وauthorization، encryption، secrets، audit trails، confidentiality، privacy، compliance، data residency، access boundaries وغيرها حسب طبيعة المنتج والسوق وبعدين بنعمل الجزء اللي ناس كتير بتتجاهله لحد ما الـ production يعملهولهم بنفسه Risk Assessment إيه أكتر 10 حاجات ممكن تضرب السيستم؟؟ بعد كدة بقى نقدر نفتي و نقول هنبني إزاي هنقسم الشغل إزاي محتاجين مين هياخد وقت قد إيه إيه الـ infrastructure المناسبة اي كلام قبل الexcercise ده هيبقى تكهنات و افكار و لا عزاء لكم الهبد و هلوسة الAI اللي بنشوفها في slides و proposals مترقعة كل يوم في البداية الموضوع هيبان عادي جدًا، خصوصًا لو المشروع صغير. بس أول ما المشروع يكبر ويحصل Error، تبدأ تسأل: المشكلة في الـ validation؟ ولا الـ business logic؟ ولا الـ DB query؟ ولا الـ request نفسه؟ لكن لما تفصل المسؤوليات: Route → Controller → Service → Repository → Database والقصة مش بس Debugging. لما المسؤوليات تبقى منفصلة، تقدر: تغيّر Database implementation من غير ما تغيّر الـ Business Logic. تغيّر طريقة استقبال الـ request من غير ما تغيّر الـ Core Logic تختبر الـ Business Logic لوحده. تعيد استخدام نفس الـ logic من أكتر من endpoint. تقلل الـCoupling بين أجزاء السيسستم. وده جوهر فكرة الـ Architecture أصلًا: مش إن الكود يبقى متقسم على folders كتير. إنما إن كل جزء يبقى مسؤول عن حاجة واضحة، والتغيير في جزء مايكسرش باقي النظام بسهولة.