ثلاثة تجريدات تحل مشكلات مختلفة
Service Layer وRepository وDomain Service ليست بدائل متنافسة. الأولى تنسق حالة استخدام، والثانية توفر الوصول إلى Aggregates أو التخزين، والثالثة تحمل منطق عمل يعبر عدة كائنات Domain ولا ينتمي طبيعيًا إلى كيان واحد.
ماذا يوضع في كل حد؟
- Application/Service Layer تملك التسلسل وحدود Transaction واستدعاء Ports.
- Repositories تعرض استعلامات مرتبطة بالمجال مثل getOpenOrder بدل تسريب تفاصيل ORM.
- Entities أو Aggregates تملك القواعد التي تعتمد على حالتها الداخلية.
- Domain Services مناسبة لقواعد مثل التسعير أو الأهلية التي تحتاج عدة مدخلات Domain.
- طبقة لا تفعل سوى تمرير الاستدعاءات تضيف تعقيدًا بلا حد تحميه.
من Controller إلى Domain والتخزين
تنسق طبقة التطبيق الطلب، وتبقى قرارات العمل داخل Domain Objects/Services، ويظل التخزين خلف Repositories.
أين يجب أن يحدث قرار العمل؟
تنسق طبقة التطبيق الطلب، وتبقى قرارات العمل داخل Domain Objects/Services، ويظل التخزين خلف Repositories.
Controller
تسعير بلا God Service
مسؤوليات في المكان الخطأ
قاعدة لتحديد مكان الكود
- اسأل هل الكود ينسق Use Case أم يصل للتخزين أم يتخذ قرار Domain.
- أبق Repositories بعيدة عن HTTP والواجهة.
- اجعل Domain Services حتمية قدر الإمكان.
- تجنب طبقات لا تفعل سوى إعادة تسمية الاستدعاء.
- اختبر قواعد Domain بلا قاعدة بيانات، واختبر Repositories تكامليًا بشكل منفصل.