الفرق بين الـ Actors، الـ Accounts، والـ Domain Entities

الفرق المفاهيمي

واحد من أكبر الأغلاط فالتصميم ديال السوفتوير هو ملي كنجمعو كلشي فـ «User» واحد، كيكون هو المسؤول على الـ authentication، والـ business logic، والتفاعل مع السيستيم. باش تبني سيستيم صحيح، خاصك تفرق بين تلاتة ديال الحوايج:

1. الـ Actor (الممثل): هو أي حاجة خارجية كتفاعل مع السيستيم باش توصل لواحد الهدف. الـ Actor هو «دور» (Role) ماشي شخص. يقدر يكون بنادم (مثلا: Courier) أو سيستيم خارجي (مثلا: Payment Gateway).
2. الـ Account (الحساب): هو الهوية اللي كنستعملوها باش ندخلو للسيستيم (Login/Password, API key) وباش نعرفو شنو مسموح ليه يدير (Authorization).
3. الـ Domain Entity (كيان المجال): هو جسم عندو هوية بيزنس فريدة كتبقى كاينة واخا يتغير شكون كيتفاعل معاها. مثلا، «الطرود» (Parcel) هي Entity؛ كتبقى كاينة وخا الـ Courier ما يكونش كيسكانيها دابا.

مثال تطبيقي: سيستيم صناديق الأمانات (Parcel Locker)

نختارو backend كحدود ديال السيستيم اللي كنرسمو. المرسل والكوريي واللي غادي يستلم كيتعاملو معاه بأدوار مختلفة. جهاز الخزنة حتى هو خارج هاد الحدود وكيعيط للـ API. إلا اعتبرنا السيستيم هو الخزنة الفيزيكية كاملة، الجهاز يقدر يولي جزء داخلي؛ تحديد actor كيتعلق بالحدود اللي اخترنا.

نفس الشخص يقدر يصيفط طرد شخصي ويوصل طرود الخدمة بنفس الحساب الدائم. وبالعكس، المستلم يقدر يفتح بكود كيتستعمل مرة وحدة بلا ما يصاوب compte. الكود دليل ديال الدخول ولا صلاحية محدودة، ماشي حساب. Application كتشوف واش الكود صالح وواش مسموح ليه بهاد الطرد، عاد كتبدل الحالة ديال الطرد والخزنة.

نموذج التطبيق: Role-Based Identity Model

باش تراجع التصميم، دير لائحة ديال المفاهيم قبل ما تصاوب class لكل actor.

الحاجة	التصنيف	علاش مهمة
المرسل	دور ديال actor	كيبين الهدف عند الحدود المختارة
الحساب A101	حساب دائم	نفس الشخص يقدر يستعملو بأدوار مختلفة
كود الاستلام	دليل دخول/صلاحية محدودة	ما كيعنيش تصاوب حساب جديد
الطرد P52	Domain entity	كيحتافظ بهويته طول التوصيل
الخزنة S8	Domain entity	عندها هوية وحالة ديال واش عامرة
الجهاز اللي كيعيط للـ backend	Actor خارجي فهاد الحدود	كيبدا interaction مع API

نفس الحاجة تقدر تبان فكثر من vue. الجهاز يقدر يكون actor فـ interaction ويكون عندو حتى سجل فـ inventory. ما خاصش كل دور يولي subclass ديال User، وماشي كل entity خاصها login.

حالات الفشل والحالات الخاصة

إلا نفس الشخص كوريي ومستلم، فرّق الدور اللي كيدير فداك التفاعل على الطرد اللي مسموح ليه يشوف. اسم الدور بوحدو ما كيثبتش ملكية الطرد. إلا المستلم كيستعمل كود، شوف الصلاحية والوقت والطرد المعني بلا ما تعتبر الكود compte دائم. وإلا تبدلات حدود السيستيم، راجع لائحة actors. هادو قرارات ديال modeling، ما كيفرضوش implementation وحدة ديال authentication.

تمرين

تقني الصيانة خاصو يفتح الخزنة باش يصلحها ويشوف diagnostics، ولكن ما يشوفش معلومات التواصل ديال المستلم فالتطبيق. شكون actor و account و entity؟

التحقق: MaintenanceTechnician دور ديال actor، والتقني يقدر يدخل بحساب ديال الموظف. LockerSlot هي entity المعنية. قواعد authorization كتتحكم فالفتح و diagnostics بلا معلومات المستلم. الدخول الفيزيكي للخزنة خاصو إجراءات تشغيلية بوحدو؛ تخبية field فالـ API ما كتضمنش أن شي واحد عندو وصول فيزيكي ما يشوفش الطرد.