التعامل مع نموذج المجال الهزيل

Question

وكنت أحاول أن فصل بلدي DAL من وجهة نظري طبقة رجال الأعمال، وبذلك، قررت أن تتجنب أي نهج أكتيفيريكورد والذهاب للنهج DataMapper. وبعبارة أخرى، فإن الأجسام نطاقي لا تأخذ الرعاية من استمرار أنفسهم. وبذلك، يبدو لي أن التعدي على "نموذج المجال الهزيل" نموذج مضاد. على سبيل المثال، واحدة من الكيانات في برنامجي هو المنظمة.

ويتم تمثيل المنظمة بوصفها شيئا من هذا القبيل:

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

وذلك أساسا وهذا التنظيم لا يفعل شيئا آخر غير بمثابة "حقيبة" (كما يقول مارتن فاولر) لبعض البيانات. في PHP للعالم أنها ليست أكثر من مجموعة وتعالى. هناك الصفر السلوك المرتبطة به.

والسلوك في البرنامج، لقد تم الشائكة في الصف "مستوى الخدمة" مثل OrganizationService الذي يخدم في الغالب كوسيط بين هذه الكائنات وDAL.

وبخلاف القضايا التحجيم المحتملة مع PHP (لدي أسباب أخرى لماذا الإصرار على "التعبئة" البيانات الخاصة بي في هذه الكائنات)، وهذا هو النهج تماما قبالة؟

وكيف تتعاملون مع نماذج نطاقك في هذه الحالات؟ ربما منظمة ليست جزءا من نطاقي في المقام الأول؟

Answer 1

وكذلك، يبدو مثل هذا في البداية، ولكن عندما كنت سوف ريفاكتور التعليمات البرمجية الخاصة بك أكثر من ذلك، سوف تحصل على بعض السلوك لفئة مؤسستك ...

واحدة سبيل المثال أنني قد يظن من الآن إذا كان لديك شخص (موظف)، قد ترغب في ربطها مع المنظمة. لذلك، قد يكون لديك AssociateEmployee(User employee) الطريقة التي قد تجد مكانها في الصف مؤسستك.

وأو قد تغيير موقع الشركة، بدلا من وضع معايير مثل العنوان والمدينة والولاية في ثلاث خطوات، يمكنك أن أضيف طريقة ChangeLocation(Street, City, State) ..

واذهبوا خطوة خطوة، عندما واجهت بعض التعليمات البرمجية في لك BL طبقة / الخدمة التي يبدو أنه يجب أن تنتمي إلى المجال، نقله الى المجال. إذا كنت تقرأ فاولر، وسوف تحصل عليه في وقت قريب جدا عندما تراه في التعليمات البرمجية.

Answer 2

قد يكون مجرد فقر الدم الآن؟

وعلى سبيل المثال، بمجرد الوقت كنت تطوير الموقع تسجيل اجتماعات / مؤتمرات. لقد بدأت مع اجتماع واحد فقط.

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

ولذا أعتقد أنه من المهم أن نأخذ في الاعتبار أن مجالات التغيير مع مرور الوقت والنموذج الخاص بك قد ينتهي الأمر ريفاكتوريد، لذلك حتى لو كنت قد يعتقد انها فقر الدم، قد يكون مجرد القليل جدا تطلعي (مثل الطبقة مؤسستك سوف تبدأ في الحصول على بعض الإعدادات أو القواعد أو تفضيلات أو شيء).

Answer 3

وكنت قد تنظر أيضا أنه إذا لم يكن لديك الكثير من قواعد العمل، أو المجال ليست مجرد أن المجمع، الذي DDD قد يكون الكثير من النفقات العامة بالنسبة لك. DDD هو حلا ممتازا لكبيرة، مجالات معقدة، ولكن الكثير من النفقات العامة والتعقيد إذا كنت ببساطة القيام البيانات في والبيانات بها. DDD أصعب لتصميم ويضيف بطبيعتها التعقيد، وذلك لتبرير ذلك، ومدى تعقيد المجال المشكلة ينبغي أن تفوق ذلك.

وهذا كل ما أود أن أضيف إلى zappan وepitka.

Answer 4

والكيان الخاص بك ليست فقر الدم بسبب كنت تأخذ reposnsibility لا ينبغي أن يكون هناك لتبدأ. استمرار وجلب الكيانات هو مسئولية أكثر من المستودعات. حقا يجب أن يكون سلوكك في كيانات الخاص بك ليس في طبقة الخدمة. ولكن شرح ما يجري فيها هو الطريق إلى ما بعد الجواب بسيط. DDD من قبل اريك ايفانز هو نقطة انطلاق جيدة.