انتقل إلى المحتوى

Clean Architecture

ما هي

تتبع الواجهة الخلفية لـ ManpowerIQ Clean Architecture: طبقات متّحدة المركز بقاعدة اعتمادية صارمة — تعتمد الطبقات الخارجية على الداخلية، ولا العكس أبدًا. يجلس Domain في المركز؛ وAPI وInfrastructure هما الأسلاك الأبعد للخارج.

مهم — لا يوجد CQRS أو MediatR. يرى قارئ .NET عبارة "Clean Architecture" فيفترض على نحو معقول خطّ أنابيب طلب/معالج MediatR. ManpowerIQ لا تستخدمه. لا توجد أنواع IRequest/IRequestHandler/IMediator في قاعدة الشيفرة. البنية قائمة على الخدمات: تعتمد المتحكّمات على أصناف خدمة عمل وتستدعيها مباشرةً عبر حقن المُنشئ. (مُتحقَّق منه 2026-06-10: grep عن MediatR/IRequestHandler/IMediator → لا تطابقات.)

لماذا بُنيت بهذه الطريقة

توجد قاعدة الاعتمادية ليبقى جوهر العمل مستقلًّا عن التسليم والاستمرارية. لا يعلم Domain (الكيانات، أشكال القواعد) وApplication (الخدمات، حالات الاستخدام) شيئًا عن EF Core، أو Postgres، أو ASP.NET، أو JWTs. ذلك الاستقلال هو ما يتيح اختبار قواعد محرّك التخصيص وآلة حالة الطلب بالوحدة دون قاعدة بيانات، ويتيح تغيير خيارات البنية التحتية دون لمس القواعد.

لم يُعتمَد MediatR: أبقى الفريق مسار الاستدعاء صريحًا — controller → service → DbContext — بدلًا من توجيه كل شيء عبر mediator. المقايضة هي طبقات توسّط أقل ومخطّط استدعاء مباشر قابل للـ grep، على حساب خطّ أنابيب السلوك العابر للقطع الذي كان MediatR سيقدّمه (والذي يُعالَج بدلًا من ذلك بالوسائط ومعترضات EF).

كيف تعمل

flowchart TB
    subgraph API[API · الطبقة الخارجية]
        C[وحدة تحكّم<br/>محروسة بالصلاحيات]
    end
    subgraph APP[Application]
        I[الواجهات<br/>ICurrentTenantProvider, IAuditLogger]
        S[أصناف الخدمة<br/>قواعد العمل]
    end
    subgraph DOM[Domain · المركز]
        E[الكيانات + التعدادات]
    end
    subgraph INFRA[Infrastructure · الطبقة الخارجية]
        IMPL[EF DbContext, CurrentTenantProvider,<br/>AuditLogger, JwtTokenMinter]
    end
    C --> S
    S --> E
    S --> I
    IMPL -. implements .-> I
    IMPL --> E
  • Domain لا يعتمد على شيء. تُشتَقّ الكيانات من AuditableEntity / TenantEntity (الورقة 01 §entities).
  • Application يعتمد على Domain فقط. يُعرِّف الواجهات للأشياء التي يحتاجها من الخارج — مثل ICurrentTenantProvider (Application/Tenancy/)، IAuditLogger (Application/Auditing/) — ويحتوي أصناف الخدمة التي تحمل قواعد العمل.
  • Infrastructure يعتمد على Application + Domain، وينفّذ تلك الواجهات: CurrentTenantProvider (الورقة 01 §build-status، Program.cs:179)، AuditLogger (AuditLogger.cs:30-65)، EF ManpowerIQDbContext، JwtTokenMinter. هذا الانعكاس (Application يملك الواجهة، Infrastructure يملك التنفيذ) هو مبدأ Dependency Inversion في الممارسة.
  • API يعتمد على Application + Infrastructure. تتلقّى المتحكّمات الخدمات عبر DI وتستدعيها مباشرةً؛ يُركَّب خطّ أنابيب الطلب ومخطّط DI في Program.cs.

تُعالَج المخاوف العابرة للقطع التي كان خطّ أنابيب MediatR سيحملها في مكان آخر بدلًا من ذلك:

مزالق / قيود

  • لا تُضِف مرجعًا Application → Infrastructure. يُعرِّف Application الواجهات؛ وينفّذها Infrastructure. إبقاء السهم مشيرًا إلى الداخل هو بيت القصيد كله.
  • لا تمدّ يدك إلى MediatR لإضافة سلوك. لا يوجد خطّ أنابيب لتوصيله. يذهب المنطق العابر للقطع في الوسائط أو معترضات EF، مطابقًا للنمط القائم.
  • التدقيق ليس مخاوف عابرة للقطع تلقائية. لعدم وجود معترض له، يجب أن تستدعي كتابةٌ جديدة ينبغي تدقيقها IAuditLogger صراحةً (الورقة 01 MUST-NOT #3).

حالة البناء

Available — البنية الطبقية القائمة على الخدمات هي البنية الحيّة. CQRS/MediatR هو Planned/غائب (غير مستخدم).

ذات صلة