Advanced Web Application Architecture
Chapter: The Domain Model – Design Entity (2.3)
في النقط اللي فاتت من الكتاب، اتكلمنا عن 3 مفاهيم مهمين جدًا:
Domain هو المجال اللي التطبيق شغال فيه (بيع كتب – حجز – توصيل… إلخ)Model هو التمثيل المنطقي للحكاية اللي البزنس عايز يحكيهاGateway طريقة نشيل بيها الـ SQL من الكود، وكل Class يمثل جدول كامل في الداتابيزولو حد حابب يرجع للنقط دي، يقدر يرجع للمقالات الي فاتت
--------------------------------------------------------
يعني إيه Design Entity؟
كلمة Design هنا معناها:
أحط حدود واضحة للحاجة اللي بعملها
يعني:
👈 إمتى أقول إن ده Order صحيح؟
👈 إمتى أقول إن ده Order بايظ؟
👈 إيه الداتا اللي لازم تكون موجودة؟
👈 وإزاي أمنع أي Order غير منطقي يدخل السيستم؟
إحنا بنحفظ إيه بالظبط؟
دي نقطة محورية جدًا 👇
إحنا مش بنحفظ شوية داتا إحنا بنحفظ Order وده فرق ضخم. لو أنا بتعامل مع array
ده مجرد Array
ملوش اسم و ملوش هوية و ملوش معنى و ملوش حماية والكمبيوتر فاهمه
بس البزنس مش باين.
الحل؟ Entity
كلمة Entity هنا معناها:
Entity = Object
يعني:
بيمثل حاجة حقيقية في الدومين
👈 ليها هوية
👈 ليها حالة
👈 وليها قوانين
في مثالنا:
Order مش شوية داتا Order = طلب حقيقي في البزنس
طيب ليه Order لازم يبقى Object؟
الكتاب بيقول الفكرة دي بشكل غير مباشر بس واضح جدًا:
إحنا عايزين ناخد طلب Ebook
ونحفظه ونرجع نستخدمه تاني ونعتمد عليه في أجزاء تانية من السيستم
يعني Order:
هيتخزن و هيتجاب تاني و هروح استخدمه ف
👈 Payment
👈 Fulfillment
👈 Reporting
------------------------------------------------------------------------------------------
ده مش Temporary Data ده حاجة لها حياة جوه السيستم وده تعريف الـ Entity حرفيًا. فمينفعش يبقى حاجة هشة.
------------------------------------------------------------------------------------------
الكتاب قالها صريحة قبل ما نحفظ Order لازم نضمن إنه كامل وصحيح
👈 علشان متكلمش العميل بعدين تقوله "معلش الإيميل غلط"
👈 علشان أي Module تاني يستخدمه: وهو مطمّن من غير ما يعيد Validation
👈 علشان اللي في DB يبقى موثوق مش Garbage
------------------------------------------------------------------------------------------
أول محاولة: Order كـ Object
ده تحسن؟ آه
بس لسه ناقص حاجة خطيرة…
ينفع أعمل كده:
يعني:
👈 Object شكله محترم
👈 بس بزنسياً بايظ
--------------------------------------------------------------------------------------------------
الحل الحقيقي: Entity تحمي نفسها زي م ذكرناا فوق تمام الEntity اتعملت علشان تحمي البزنس مش علشان تنظّم الكود ولا علشان OOP وخلاص لو Order دخل السيستم يبقى Order صح أو ما يدخلش خالص وده سبب وجود الـ Entity.
--------------------------------------------------------------------------------------------------
مينفعش Order يتخلق غلط و بكدا الغلط يطلع بدري
أي Order جوه السيستم = Order محترم
نقطة مهمة جدًا
👈 الـ Entity مش مسؤولة عن عرض Errors
1 - Validation Forms2 -UXمسؤولة عن:
حماية نفسها و رفض أي Order غير منطقي
Assertions ≠ User Validation
Validation المستخدم: UI / Form
Assertions: Domain Protection
الخلاصة اللي في دماغ الكتاب (بعد المقارنة فعليًا)
بعد ما نقارن الكودين دول:
الكود القديم (Array + Gateway فقط)
والكود بعد إدخال الـ Entities
Ebook = كائن له معنىOrder = كائن له قوانينAssertions جوّه الدومين
أي Order جوّه السيستم
Order سليم غصب عنك
مفيش Order “نص مش مضبوط”
مفيش Ebook “سعره صفر”
--------------------------------------------------------------------------------------------------
❗ المشكلة اللي لسه موجودة (والكتاب واضح فيها) Gateway لسه عايز array
Domain بيتكلم Objects
Infrastructure بيتكلم Arrays
Controller لسه:
بيحوّل وبيفك وبيربط الاتنين ببعض
--------------------------------------------------------------------------------------------------
وهنا الكتاب بيقولك اي بقا
لما تلاقي Domain بيتكلم Objects و Persistence عايزة Arrays يبقى إنت جاهز لطبقة جديدة
يعني
لما تحس إن الـ Object مش عارف يتحفظ لوحده يبقى انت محتاج abstraction جديد
و اظن عرفت عنوان المقالة الجاية بقا
👈Repository
