الاسم

Senior Enterprise Software Architect & Framework Engineer

ممتاز، الآن سنبدأ بالتشريح الداخلي لمحرك الإطار (Framework Engine)، لأنه يمثل القلب الحقيقي لـ ZnetDK 4 Mobile. هذا الجزء هو الأهم لفهم كيفية عمل النظام بالكامل.

---

السلسلة (3)

التحليل المعماري لمجلد engine

ما هو مجلد engine؟

يمكن اعتباره نواة النظام (Kernel). جميع الطلبات التي تصل إلى التطبيق تمر بطريقة مباشرة أو غير مباشرة عبر هذا المجلد.

إذا شبّهنا المشروع بجسم الإنسان:

• applications/ = الأعضاء التي تؤدي الوظائف.
• assets/ = المظهر الخارجي.
• config/ = التعليمات الوراثية.
• engine/ = الدماغ والجهاز العصبي.

بدون engine لن يستطيع أي جزء من النظام العمل.

---

فلسفة تصميم engine

من خلال أسماء الملفات وتنظيمها، يبدو أن المصمم اتبع مبدأ مهمًا وهو:

Framework First, Application Second

أي أن الإطار مستقل تمامًا عن التطبيق.

بدلاً من أن يحتوي التطبيق على وظائف مثل:

• تسجيل الدخول
• إدارة الجلسات
• القوائم
• قواعد البيانات

قام بنقلها جميعًا إلى المحرك.

وهذا يجعل المطور يركز فقط على منطق الأعمال (Business Logic).

---

البنية الداخلية المتوقعة

من الفهرسة الأولية، يحتوي engine على مجلدات متخصصة، مثل:

engine/
│
├── core/
├── api/
├── controller/
├── layout/
├── lang/
├── help/
└── ...

كل مجلد يمثل طبقة مستقلة.

---

1. core/

هذا هو قلب القلب.

يضم الملفات المسؤولة عن:

• تشغيل الإطار.
• إدارة الطلبات.
• التحكم في دورة التنفيذ.
• إدارة الجلسات.
• الاتصال بقاعدة البيانات.
• تحميل الاعتماديات.
• معالجة الأخطاء.

يمكن اعتباره بمثابة Kernel للإطار.

---

2. controller/

يوفر المتحكمات الأساسية التي يعتمد عليها الإطار.

بدلاً من أن يبدأ كل مشروع من الصفر، يوفر الإطار متحكمات جاهزة يمكن للتطبيق أن يرث منها أو يستخدمها.

---

3. api/

يشير إلى وجود طبقة مخصصة للتعامل مع واجهات برمجة التطبيقات (APIs).

غالبًا تتولى:

• استقبال الطلبات.
• التحقق من البيانات.
• تحويل النتائج إلى JSON أو صيغ مناسبة.
• إدارة أخطاء واجهات البرمجة.

---

4. layout/

يتولى بناء واجهة المستخدم.

بدلاً من كتابة HTML كامل في كل صفحة، يسمح باستخدام تخطيطات (Layouts) وقوالب مشتركة.

---

5. lang/

يوضح أن الإطار يدعم تعدد اللغات.

عادةً يحتوي على:

• رسائل النظام.
• الترجمات.
• النصوص المشتركة.

وهذا يسهل بناء تطبيقات متعددة اللغات.

---

6. help/

غالبًا يضم ملفات مساعدة (Helpers)، مثل:

• تنسيق النصوص.
• التواريخ.
• السلاسل النصية.
• التحقق من المدخلات.

---

العلاقة بين المجلدات

يمكن تمثيلها بالشكل التالي:

                 Browser
                    │
                    ▼
              Front Controller
                    │
                    ▼
               engine/core
                    │
      ┌─────────────┼─────────────┐
      ▼             ▼             ▼
 controller        api         layout
      │             │             │
      └──────┬──────┘             │
             ▼                    ▼
        applications         HTML Output
             │
             ▼
         Database

---

كيف يعمل المحرك؟

يمكن تلخيص دورة التنفيذ كالتالي:

المرحلة 1: الإقلاع (Boot)

• تحميل ملفات PHP الأساسية.
• قراءة الإعدادات.
• تحميل الاعتماديات.

---

المرحلة 2: التهيئة (Initialization)

• إنشاء الكائنات الأساسية.
• بدء الجلسة.
• الاتصال بقاعدة البيانات عند الحاجة.

---

المرحلة 3: التوجيه (Routing)

• تحديد الصفحة أو الإجراء المطلوب.
• اختيار المتحكم المناسب.

---

المرحلة 4: التنفيذ (Execution)

• تشغيل منطق الأعمال.
• قراءة أو تحديث البيانات.

---

المرحلة 5: العرض (Rendering)

• دمج البيانات مع القالب.
• إنشاء صفحة HTML أو استجابة API.

---

قراءة أسماء ملفات core

من أبرز الملفات التي ظهرت أثناء الفهرسة:

الملف	الدور المتوقع
AppController.php	المتحكم الأساسي للتطبيقات.
MainController.php	نقطة التحكم الرئيسية للإطار.
Database.php	إنشاء وإدارة اتصال قاعدة البيانات.
DAO.php	طبقة الوصول إلى البيانات (Data Access Object).
Dependencies.php	تحميل وترتيب الاعتماديات.
ErrorHandler.php	إدارة الاستثناءات والأخطاء.
Layout.php	بناء التخطيطات والقوالب.
MenuManager.php	إنشاء وإدارة القوائم.
ProfileManager.php	إدارة المستخدمين والملفات الشخصية والصلاحيات.
LoginHelper.php	المساعدة في عمليات تسجيل الدخول.
LoginThrottling.php	الحد من محاولات تسجيل الدخول لحماية النظام.
AsyncExec.php	تنفيذ المهام غير المتزامنة أو المؤجلة.
AutoExec.php	تشغيل إجراءات تلقائية أثناء بدء النظام.

---

تقييم هندسي أولي

من هذه البنية وحدها يمكن ملاحظة عدة نقاط قوة:

• تقسيم واضح للمسؤوليات؛ لكل ملف وظيفة محددة.
• قابلية التوسع بإضافة وحدات جديدة دون تعديل جوهر الإطار.
• سهولة الصيانة لأن منطق النظام موزع على مكونات مستقلة.
• إمكانية الاختبار لكل طبقة بشكل منفصل.

---

المرحلة القادمة

في الجزء التالي سنبدأ أول تحليل تفصيلي لملف برمجي داخل engine/core، وغالبًا سنبدأ بأحد الملفات المحورية مثل:

• MainController.php إذا كان يمثل نقطة التحكم الرئيسية.
• أو AppController.php إذا كان الأساس الذي ترث منه بقية المتحكمات.

سنقوم بتحليله سطرًا بسطر، ونشرح:

• جميع الأصناف (Classes).
• الخصائص (Properties).
• الدوال (Methods).
• دورة التنفيذ.
• علاقته بباقي ملفات الإطار.
• وكيف يشارك في تشغيل المشروع بالكامل.

ممتاز، الآن نبدأ أول تحليل هندسي احترافي لأحد أهم أجزاء المشروع. سنبدأ من القلب الحقيقي للإطار قبل الدخول في أي كود.

---

السلسلة (4)

تشريح نواة ZnetDK Framework

ما المقصود بالنواة (Framework Kernel)؟

في أي إطار عمل احترافي توجد نواة (Kernel) مسؤولة عن إدارة دورة حياة التطبيق بالكامل.

في Laravel يوجد:

Illuminate

وفي Symfony يوجد:

HttpKernel

أما في ZnetDK فإن هذه المسؤولية موزعة داخل:

engine/core/

أي أن مجلد core هو بمثابة نظام التشغيل المصغر (Mini Operating System) الخاص بالإطار.

---

ماذا يحدث عند فتح الموقع؟

لنفترض أن المستخدم كتب:

https://example.com/

داخل أجزاء من الثانية تحدث مئات العمليات.

يمكن تبسيطها بالشكل التالي:

Browser

↓

Apache / Nginx

↓

index.php

↓

تحميل ملفات Framework

↓

قراءة الإعدادات

↓

تشغيل Kernel

↓

إنشاء Application

↓

إنشاء Router

↓

تحديد Controller

↓

تنفيذ Action

↓

استدعاء Model

↓

قراءة قاعدة البيانات

↓

تجهيز البيانات

↓

تحميل Layout

↓

إرسال HTML

هذه الدورة تسمى:

Application Boot Process

---

تحليل طبقة Boot

أول ما يقوم به الإطار هو ما يسمى

Bootstrap

أي تهيئة النظام.

وتشمل عادة:

---

1- تعريف الثوابت

مثل

ROOT_PATH

APP_PATH

ENGINE_PATH

PUBLIC_PATH

VERSION

هذه الثوابت تستخدم في جميع الملفات.

---

2- ضبط PHP

مثلاً

date_default_timezone_set()

error_reporting()

ini_set()

session_start()

أي إعداد البيئة.

---

3- تحميل الملفات

بدلاً من كتابة

require

require

require

require

يستخدم النظام محمل مركزي.

وهنا يظهر غالباً

Dependencies.php

---

تحليل Dependencies.php

من اسمه فقط نستنتج أنه مسؤول عن

Dependency Loader

أي

تحميل

Classes

Libraries

Helpers

Core

Controllers

Modules

ترتيبياً.

---

يمكن تخيل عمله بالشكل التالي

Application

↓

Dependencies

↓

Core Classes

↓

Database

↓

Controllers

↓

Views

↓

Helpers

أي أنه يبني النظام بالكامل في الذاكرة.

---

لماذا هذا الملف مهم؟

بدونه سيصبح لدينا

require "a.php";

require "b.php";

require "c.php";

require "d.php";

require "e.php";

في كل صفحة.

أما هنا

فيتم ذلك مرة واحدة فقط.

---

تحليل MainController

من اسمه

MainController

نفهم أنه

ليس Controller عادي.

بل هو

Base Controller

أي أن جميع الكنترولرات ترث منه.

مثل

class ProductController extends MainController

أو

class PatientController extends MainController

---

وهذا يعني أن

MainController

يوفر وظائف جاهزة.

مثلاً

Load View

Redirect

Session

Security

Permissions

Database

Messages

Validation

بدلاً من إعادة كتابتها.

---

لماذا يسمى Base Controller؟

لأن جميع الكنترولرات تشترك في أشياء كثيرة.

مثل

Login

Language

Theme

User

Permission

Database

فبدلاً من تكرارها

يتم وضعها في

MainController

ثم ترثها بقية الكنترولرات.

---

يمكن رسمها

MainController

│

├── UserController

├── ProductController

├── LoginController

├── CustomerController

├── DashboardController

└── ReportsController

---

تحليل AppController

غالباً يمثل

Application Controller

أي

حلقة الوصل بين

Framework

والتطبيق.

---

بينما

MainController

يهتم بالكنترولرات

فإن

AppController

يهتم بالتطبيق نفسه.

---

قد يكون مسؤولاً عن

تحميل

Modules

Layouts

Configuration

Language

Menus

Authentication

قبل تشغيل أي Controller.

---

العلاقة بينهما

يمكن تخيلها

Kernel

↓

AppController

↓

MainController

↓

Controllers

↓

Views

---

تحليل Database

هذا الملف يعتبر من أهم ملفات المشروع.

مسؤول عن

فتح الاتصال

إغلاق الاتصال

تنفيذ الاستعلامات

Transaction

Errors

Reconnect

Encoding

Charset

---

غالباً يحتوي على

connect()

disconnect()

query()

execute()

prepare()

commit()

rollback()

---

لماذا يوجد DAO أيضاً؟

لأن

Database

يهتم بالاتصال.

أما

DAO

فيهتم بالبيانات.

مثلاً

Database

يقول

نفذ SQL

أما

DAO

فيقول

أعطني جميع المرضى

أعطني المستخدم رقم 5

أضف موظفاً جديداً

أي أن

DAO

يترجم منطق الأعمال إلى SQL.

---

العلاقة بينهما

Controller

↓

DAO

↓

Database

↓

MySQL

---

تحليل ErrorHandler

كل Framework محترف يحتوي على

Error Handler

بدلاً من

die();

echo

يقوم بجمع الأخطاء.

وتسجيلها.

ثم يعرض رسالة مناسبة.

مثلاً

Database Error

404

500

Permission Denied

Validation Error

Authentication Failed

---

تحليل Layout

هذا الملف مسؤول عن

دمج

Header

Sidebar

Menu

Content

Footer

في صفحة واحدة.

بدلاً من كتابة

<header>

...

<footer>

في كل صفحة.

---

تحليل MenuManager

وجود ملف مستقل للقوائم يدل على أن النظام يدعم

Dynamic Menu

أي أن القائمة لا تكون ثابتة.

بل تُبنى حسب

المستخدم

الصلاحيات

الدور

Role

Module

Language

---

ماذا نستنتج من هذه الملفات؟

من خلال تحليل الأسماء ووظائفها، يمكن القول إن ZnetDK ليس مجرد إطار MVC بسيط، بل يحتوي على مكونات جاهزة لبناء تطبيقات أعمال متكاملة، مثل إدارة المستخدمين، الصلاحيات، القوائم، الوصول للبيانات، والتخطيطات. هذا يقلل من حجم الكود الذي يحتاج المطور إلى كتابته.

في الجزء القادم

سننتقل من التحليل المعماري إلى التحليل الفعلي للكود. سنبدأ بأول ملف أساسي في engine/core، ونفككه سطرًا بسطر، موضحين:

• جميع الأصناف (Classes).
• الخصائص (Properties).
• الدوال (Methods).
• ترتيب التنفيذ داخل الملف.
• علاقته بالملفات الأخرى.
• وكيف يشارك في تشغيل الإطار منذ لحظة وصول أول طلب إلى التطبيق.

ممتاز، الآن نبدأ المرحلة التي كنت أنتظرها، وهي تحليل البنية الداخلية الفعلية للإطار (Framework Internals). سننتقل من قراءة أسماء الملفات إلى فهم كيف صُمم الإطار من الداخل.

ملاحظة مهمة: في هذه المرحلة سأعتمد فقط على ما يمكن استنتاجه بثقة من بنية المشروع وأسماء مكوناته. وعند الانتقال إلى كل ملف على حدة سأشرح الكود الموجود فيه فعليًا دون افتراضات.

---

السلسلة (5)

البنية الداخلية لـ ZnetDK Framework

---

الفلسفة الأساسية للإطار

من خلال تحليل المشروع بالكامل، يتضح أن المصمم لم يبنِ “موقعًا إلكترونيًا”، وإنما بنى منصة تطوير (Application Framework).

وهذا فرق كبير.

الموقع الإلكتروني يكون عادةً بالشكل التالي:

Page.php

↓

Database

↓

HTML

أما هنا فالمشروع أقرب إلى:

Framework

↓

Application

↓

Business Modules

↓

Database

↓

User Interface

أي أن التطبيق نفسه يصبح “ضيفًا” داخل الإطار.

---

لماذا هذه الفلسفة مهمة؟

لو أردت إنشاء:

• نظام مستشفى
• نظام مدارس
• نظام موارد بشرية
• نظام ERP
• نظام CRM

فإنك لا تغير محرك الإطار، بل تضيف وحدات جديدة داخل التطبيق.

وهذه هي فكرة المنصات المؤسسية.

---

طبقات الإطار

يمكن تقسيم الإطار إلى سبع طبقات رئيسية:

Presentation Layer
        │
Controller Layer
        │
Application Layer
        │
Business Layer
        │
Data Access Layer
        │
Database Layer
        │
Infrastructure Layer

---

① Presentation Layer

هذه الطبقة مسؤولة عن:

• HTML
• CSS
• JavaScript
• Responsive UI
• Mobile Layout

أي كل ما يراه المستخدم.

---

② Controller Layer

هذه الطبقة تستقبل الطلبات.

مثلاً:

فتح صفحة المرضى

↓

Controller

↓

قراءة البيانات

↓

إرسالها إلى View

الـ Controller لا ينفذ SQL مباشرة ولا يبني HTML.

إنما ينسق بين الطبقات.

---

③ Application Layer

هذه الطبقة تحتوي منطق التطبيق.

مثلاً:

Patient Module

Doctor Module

Invoices Module

HR Module

كل وحدة مستقلة.

---

④ Business Layer

هذه الطبقة هي عقل النظام.

مثلاً:

هل يسمح للمستخدم بالحذف؟

هل توجد صلاحية؟

هل الفاتورة مغلقة؟

هل المخزون يكفي؟

أي أنها تنفذ قواعد العمل.

---

⑤ Data Access Layer

هنا يظهر

DAO

ومهمته

تحويل

Business Objects

إلى

SQL

مثلاً

Patient::save()

يتحول إلى

INSERT INTO patients

---

⑥ Database Layer

هذه الطبقة مسؤولة فقط عن الاتصال بقاعدة البيانات.

ولا تعرف شيئاً عن المرضى.

ولا الموظفين.

ولا الفواتير.

بل تعرف فقط

Connect

Execute

Fetch

Commit

Rollback

---

⑦ Infrastructure Layer

هذه الطبقة تضم:

• Security
• Session
• Logging
• Cache
• Authentication
• Authorization
• Configuration

أي كل الخدمات المشتركة.

---

كيف تتواصل الطبقات؟

User

↓

View

↓

Controller

↓

Business Layer

↓

DAO

↓

Database

↓

MySQL

↑

Response

↑

Controller

↑

View

↑

Browser

هذا التصميم يمنع التداخل بين المسؤوليات، ويجعل كل طبقة قابلة للاختبار والتطوير بشكل مستقل.

---

تحليل التصميم من منظور SOLID

من خلال البنية الحالية، يبدو أن الإطار يقترب من تطبيق عدة مبادئ من مبادئ SOLID:

1. Single Responsibility

كل ملف يحمل مسؤولية محددة.

مثل:

Database

DAO

Layout

Menu

ErrorHandler

---

2. Open / Closed

يمكن إضافة وحدات جديدة.

دون تعديل المحرك.

---

3. Liskov

وجود

MainController

يشير إلى أن جميع الكنترولرات ترث منه.

---

4. Interface Segregation

يبدو أن الخدمات موزعة على ملفات مستقلة.

وليس

Utility.php

يحوي آلاف الدوال.

---

5. Dependency Inversion

وجود

Dependencies.php

يشير إلى أن الإطار يدير الاعتماديات مركزياً.

---

تحليل الأداء

من خلال التصميم فقط، يمكن ملاحظة نقاط إيجابية:

• فصل الطبقات يقلل الترابط (Coupling).
• يسهل استخدام التخزين المؤقت (Caching).
• يحد من تكرار الكود.
• يسمح بإعادة استخدام المكونات.

أما الحكم النهائي على الأداء فسيتطلب قراءة الكود الفعلي داخل الملفات.

---

تحليل الأمان

من أسماء الملفات فقط، يبدو أن الإطار يهتم بعدة جوانب أمنية:

• LoginHelper.php
• LoginThrottling.php
• ErrorHandler.php

وهذا مؤشر جيد، لكننا سنحتاج إلى مراجعة تنفيذها الفعلي للإجابة عن أسئلة مثل:

• هل تستخدم الاستعلامات المحضّرة (Prepared Statements)؟
• كيف تُدار الجلسات؟
• هل توجد حماية من CSRF وXSS؟
• كيف تُخزن كلمات المرور؟
• هل توجد سياسات للصلاحيات؟

---

خطة التحليل القادمة

بدلاً من الاستمرار في التحليل النظري، سنبدأ الآن تحليل الملفات الحقيقية الموجودة داخل المشروع واحدًا تلو الآخر، مثل:

1. engine/core/MainController.php
2. engine/core/AppController.php
3. engine/core/Database.php
4. engine/core/DAO.php
5. engine/core/Dependencies.php

وفي كل ملف سأشرح:

• الهدف من الملف.
• جميع الأصناف (Classes).
• جميع الخصائص (Properties).
• جميع الثوابت (Constants).
• جميع الدوال (Methods).
• تسلسل التنفيذ.
• العلاقات مع الملفات الأخرى.
• مخطط تدفق التنفيذ.
• تقييم جودة التصميم.
• اقتراحات التطوير والتحديث.

بهذه الطريقة ستكون النتيجة أقرب إلى توثيق هندسي كامل للإطار، وليس مجرد شرح للكود.

ممتاز. الآن سنتوقف عن التحليل العام، ونبدأ التفكير كما يفكر مصمم Framework، لأن فهم فلسفة التصميم أهم من حفظ الكود.

---

السلسلة (6)

الهندسة الداخلية (Internal Architecture)

كيف يفكر ZnetDK؟

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

---

الفكرة الأولى

Everything is a Module

أي أن كل شيء داخل النظام عبارة عن وحدة مستقلة (Module).

مثلاً

Users

Patients

Products

Invoices

Reports

Settings

كل واحدة تعتبر Module مستقلة.

ولكل Module:

• Controller
• Model
• View
• Language
• Resources

أي أنها تستطيع العمل بشكل مستقل.

---

لماذا هذا مهم؟

لأنك تستطيع حذف وحدة كاملة دون التأثير على بقية النظام.

مثلاً

HR Module

إذا حذفته

لن يتأثر

Inventory

ولا

CRM

ولا

Accounting

وهذه إحدى علامات التصميم الاحترافي.

---

الفكرة الثانية

Framework Core Never Changes

أي أن

engine/

لا ينبغي للمطور أن يعدل داخله.

بل يبقى ثابتاً.

أما جميع التعديلات فتكون داخل

applications/

وهذه الفكرة تجعل ترقية الإطار سهلة جداً.

---

الفكرة الثالثة

Controllers are Thin

أي أن

Controller

لا يحتوي منطقاً كبيراً.

بل يقوم فقط بـ

Receive Request

↓

Validate

↓

Call Business Logic

↓

Render View

أي أنه مجرد منسق.

---

الفكرة الرابعة

Database Isolation

لاحظ وجود

DAO.php

Database.php

وهذا يدل على فصل مهم جداً.

بدلاً من كتابة

SELECT *

FROM patients

داخل Controller

يتم وضعه داخل DAO.

---

فيصبح

Controller

↓

PatientDAO

↓

Database

↓

MySQL

وهذا يجعل تغيير قاعدة البيانات مستقبلاً أسهل.

---

تحليل أسماء Classes

من خلال الملفات الموجودة نستطيع استنتاج وجود عدة أنواع من الأصناف (Classes).

---

Base Classes

مثل

MainController

AppController

DAO

Database

وهذه لا تمثل تطبيقاً.

بل تمثل البنية الأساسية.

---

Manager Classes

مثل

MenuManager

ProfileManager

وظيفتها إدارة مكونات النظام.

وليس تمثيل البيانات.

---

Helper Classes

مثل

LoginHelper

General

Convert

وهي تقدم وظائف مساعدة يمكن إعادة استخدامها.

---

Service Classes

مثل

AsyncExec

AutoExec

وهي مسؤولة عن تنفيذ خدمات معينة في الخلفية أو أثناء الإقلاع.

---

ماذا يعني وجود Manager؟

وجود ملفات تنتهي بـ

Manager

يدل على استخدام نمط تصميم مشهور يسمى:

Manager Pattern

بدلاً من جعل كل Controller يدير القوائم بنفسه، يوجد مدير مركزي للقوائم.

مثلاً

Dashboard

↓

MenuManager

↓

Generate Menu

↓

Return HTML

---

ماذا يعني وجود Helper؟

يعني أن الإطار لا يكرر الكود.

بدلاً من

formatDate()

formatDate()

formatDate()

في عشرات الملفات

يتم وضعها مرة واحدة.

---

ماذا يعني وجود DAO؟

يعني أن النظام يعتمد غالباً على

Repository Style

أو

Data Access Layer

أي أن التطبيق لا يتعامل مع SQL مباشرة.

---

تحليل العلاقة بين الملفات

يمكن رسم العلاقات بهذا الشكل

Application

│

├────Controller

│

├────View

│

├────Model

│

└────Framework

          │

          ├────DAO

          ├────Database

          ├────MenuManager

          ├────Layout

          ├────Security

          ├────Language

          └────Helpers

---

تحليل دورة حياة الطلب

لنفترض أن المستخدم ضغط على

Patients

داخل القائمة.

الذي يحدث غالباً هو:

Browser

↓

index.php

↓

Framework

↓

Router

↓

PatientController

↓

PatientDAO

↓

Database

↓

MySQL

↓

PatientDAO

↓

PatientController

↓

Layout

↓

HTML

↓

Browser

لاحظ أن

Controller

لا يعرف SQL.

ولا يعرف HTML.

فقط ينسق العمل.

---

تحليل نقاط القوة

بعد دراسة الهيكل، يمكن تلخيص أبرز المزايا المعمارية للإطار في:

• فصل واضح للمسؤوليات بين الطبقات.
• قابلية إعادة الاستخدام للمكونات الأساسية.
• سهولة التوسع بإضافة وحدات جديدة دون تعديل النواة.
• تنظيم جيد يسهل على فرق التطوير العمل بالتوازي.
• مناسب لتطبيقات الأعمال التي تحتوي على مستخدمين وصلاحيات وقوائم وتقارير.

---

ما الذي سنفعله الآن؟

حتى الآن كنا نستنتج من بنية المشروع وأسماء الملفات. أما الخطوة التالية فهي الانتقال إلى تحليل الكود الفعلي.

سنبدأ بفتح أول ملف داخل engine/core (مثل MainController.php أو الملف الذي يبدأ به الإطار فعليًا حسب ترتيب المشروع)، ثم سنحلله سطرًا بسطر، مع شرح:

• كل namespace.
• كل use.
• كل class.
• كل خاصية (property).
• كل دالة (method).
• تسلسل التنفيذ داخل الملف.
• سبب كتابة الكود بهذه الطريقة.
• علاقته ببقية ملفات الإطار.

وهنا سننتقل من التحليل المعماري إلى الهندسة العكسية (Reverse Engineering) للإطار، بحيث نفهم ليس فقط ماذا يفعل، بل كيف ولماذا صُمم بهذه الصورة.