ليس من الضروري -أو حتى ليس من الممكن- أن نصل إلى التصميم الأمثل في البرمجيات من أول او ثاني محاولة.
فلكل مقام مقال و هناك مقولة Make it then Enhance it. "اصنعه ثم حسّنه". هنا سأختصر بعض الطرق في الSoftware Designing و الArchitecture و متى أين نستخدمها.
(سلسلة)
فلكل مقام مقال و هناك مقولة Make it then Enhance it. "اصنعه ثم حسّنه". هنا سأختصر بعض الطرق في الSoftware Designing و الArchitecture و متى أين نستخدمها.
(سلسلة)
اذا كان لديك تطبيق بسيط و مؤقت اصنعه بأسهل الطرق لديك. قد يكون على الConsole و كل الLogic بداخل كلاس واحد كبير.
و اذا كان Desktop بسيط فضع الLogic في الEvent الخاص بضغط الButton مثلاً. فهذا ليس خطأ مادام ان البرنامج صغير و بسيط ويؤدي المطلوب منه.
و اذا كان Desktop بسيط فضع الLogic في الEvent الخاص بضغط الButton مثلاً. فهذا ليس خطأ مادام ان البرنامج صغير و بسيط ويؤدي المطلوب منه.
اما و إذا كان المطلوب تطبيق Web صغير و الميزانية محدودة وكذلك الوقت فاستخدم نمط MVC مثلاً و ضع اللوجيك بداخل الController مباشرة بما في ذلك الربط مع قواعد البيانات سواء مباشرة او من خلال ORM. هذا ايضاً مقبول , إلا إن كنت تتوقع ان تتضخم المتطلبات بشكل كبير قريباً.
إن كنت تتوقع متطلبات اكثر فخذ ما كتبته من Methods بداخل الController و ضعه في مشروع كـLayer جديدة و سمه Service او يمكن تسميته Application. و قم بمناداة من خلال الControllers.
مشروع الService سيفيدك هنا حتى في حالة اردت إنشاء مشروع لطبقة أخرى Api لبرنامجك بحيث يمكن التواصل معه من الخارج
من خلال تطبيق هاتفي او Integration مع نظام اخر او فصل الUI تماماً بتقنيات مثل الJS Frameworks كـReact و Vue و Angular و غيرها.
من خلال تطبيق هاتفي او Integration مع نظام اخر او فصل الUI تماماً بتقنيات مثل الJS Frameworks كـReact و Vue و Angular و غيرها.
الMethods التي نقلناها من الControllers كانت تحتوي Business Logic مع Persistence Logic الPersistence
يعني الحفظ في قواعد البيانات او في وسيلة اخرى , قد تكون ملف نصي و قد تكون Api لخدمة تخزين سحابية.
يعني الحفظ في قواعد البيانات او في وسيلة اخرى , قد تكون ملف نصي و قد تكون Api لخدمة تخزين سحابية.
يمكن فصل هذا الجزء المتعلق بالحفظ في كلاسات مستقلة تسمى Repository و هذا نمط من انماط التصميم يفيدك في فصل ذلك الجزء و يسهل عليك تغييرها في المستقبل فمثلاً قد تستبدل MySQL بـMongoDB او أي وسيلة تخزين اخرى من دون ان تغير باقي اجزاء برنامجك.
يمكن التحسين اكثر بأن تأخذ الكلاسات الأساسية او ما تسمى بالEntities مثل Employee و Product و Order و تضعها في مشرو ع مستقل تسميه Domain او Core
بحيث يكون المشروع هو لب التطبيق , الجميع يقرأ منه بما فيهم الservice و لا يقرأ من أحد أو بمعنى اخر لا يعتمد على أحد و الكل يعتمد عليه.
بحيث يكون المشروع هو لب التطبيق , الجميع يقرأ منه بما فيهم الservice و لا يقرأ من أحد أو بمعنى اخر لا يعتمد على أحد و الكل يعتمد عليه.
هذه الطريقة او الهيكلة تسمى الClean Architecture تختلف عن الN-Tier ففي الثانية تجد الData Layer هي الأساس لكن في الClear Architecture ستجدها في الInfrastructure و تعتمد على على الDomain و ليس العكس. يمكن هذا من خلال الDependency Injection الذي سأذكره لاحقاً.
سنحاول تحسين البرنامج أكثر , ارجع للMethods في الـ Application or Service Layer ستجد ان بعضها وضيفتها القراءة و اخرى وضيفتها الكتابة يمكنك فصلها باستخدام نمط CQRS. سيكون هناك كلاسات في مجلد جديد اسمه Commands للكتابة و كلاسات للقراءة في مجلد Queries. و يستقبل كلاهما Requests.
إذا كبر البرنامج و اصبح يتلقى مئات الRequests المختلفة و اصبح هناك اكثر من شيء عليك عمله عند وصول الRequest مثل الحفظ , كتابة Log ارسال Email مناداة api خارجية .. هنا تحتاج لاحد انماط التصميم و هو الMediator Pattern. بحيث يكون نقطة التواصل بين الObjects المختلفة
و هكذا تفصل العمليات السابقة في كلاسات مستقلة كلها تقرأ من ذلك الMediator. او بالأصح الMediator هو نقطة التوزيع الرئيسية بينهم.
الMediator Pattern هو أساس تقنيات كثيرة مثل Messaging brokers كـ Kafka او RabbitMQ او Azure Service Bus.
عادة في التقنية لا شيء جديد لكن الفرق هنا ان استخدام الMediator يعتبر Designing و استخدام Kafka يعتبر Architecture.
عادة في التقنية لا شيء جديد لكن الفرق هنا ان استخدام الMediator يعتبر Designing و استخدام Kafka يعتبر Architecture.
الDependency Injection شيء مهم جداً و اساس في تصميم البرمجيات. فكرته انه بدل أن تقول لكلاس معين اعتمد على هذا الكلاس مباشرة من خلال الكود يمكن أن ترسل له في كل مرة ذلك الObject كـparameter إي تحقنه به وقت التشغيل و ليس في الكود و من هنا اتت كلمة Injection
البرامج تحتاج الError Handling و Validations و Logging يمكنك عمل كلاس مستقل لهذه الوظيفة بدل أن تكرر كتابته في كل Method . كل ما وزعت اجزاء البرنامج كلما سهل عليك التعديل عليها في مكان واحد و سهل ايضاً عملية الTesting لها.
ماذا بقي ؟ الDDD؟ الDDD ليس مهما أن تطبقها بحذافيرها لكن فيها اشياء مفيدة هي مكونة من ماذكر سابقاً فيها Repository و فيها Services و Events كالتي استخدمناها في الCQRS لكنها مفيدة في تفصيل الكلاسات حسب وظائفها في النظام لتسهل تفكيك المشاريع ذات الlogic المعقد.
ايضاً لدينا الEvent Driven Architecture و هي ان تفكر في البرنامج من ناحية انه مكان لتسجيل احداث متتالية حدثت في الماضي ولا تتغير و تعتمد ايضا على الCQRS بالإضافة إلى فصل قواعد بيانات القراءة تماماً عن الكتابة و تتم القراءة عن طريق آلية تسمى Projection.
كلما كان المشروع كبيراً و بميزانية عالية كلما كان علينا اعطاء وقت و أهمية اكبر لمرحلة التصميم. فإذا كان البرنامج صغير و التصميم اعقد مما نحتاجه فهذا سوء تصميم و العكس صحيح في حال ان النظام عقد لكن تصميمه بسيط. ومن الافضل ان يتحسن التصميم دورياً من خلال الRefactoring حسب الحاجة.
في هذه الأيام يمكن لبرنامج كلف 10 الاف دولار أن يدخل مليون دولار إذا انطلق و وصل للسوق اولاً ثم من هذه المليون قد يستبدل اكثر من مرة. هذا الشيء هو الذي جعل الشركات لا تركز كثيراً في موضوع التصميم في البداية لأنه يأخذ وقت و الوقت لديها أهم من تكلفة اضافة خوادم او مبرمجين لاحقاً.
ذكرت مصطلحات كثيرة يمكن ايجاد شرح و امثله و مشاريع جاهزة لها بلغة البرمجة التي تستخدمها. فكلها قابلة للتطبيق في باغلب لغات البرمجة التي تدعم الOOP. ابدأ بمقال او فيديو لا يتعدى عشر دقائق ثم حاول تطبيقه. فالأمر مهما بدا معقداً فخلفه مباديء بسيطة.
أن نعرف فائدة الشيء و متى ثم أين نستخدمه و نفهم الصورة الكبيرة له أهم من الدخول في تفاصيله و كيف نستخدمه , دائماً دع كيف آخر اسئلتك. لا يوجد في التصميم صح و خطأ هناك فقط تصميم أفضل من آخر لكل حالة.
عذراً على الإطالة و دمتم.
عذراً على الإطالة و دمتم.
جاري تحميل الاقتراحات...