ما ينتمي إلى الجذر الكلي

Question

هذا سؤال عملي للتصميم المستند إلى المجال:

من الناحية النظرية، أعتقد أنني سأحصل على جذور مجمعة حتى أقوم بتحديد واحدة.

لدي كيان موظف، والذي ظهر كجذر مجمع.في العمل، بعض يمكن تسجيل مخالفات العمل ضد الموظفين:

الموظف-----*المخالفات

وبما أنه ليس كل الموظفين يخضعون لهذا، أعتقد أن المخالفات لن تكون جزءًا من إجمالي الموظفين، أليس كذلك؟

لذا، عندما أرغب في العمل مع الموظفين والانتهاكات ذات الصلة بهم، هل يتم تفاعل المستودعين المنفصلين بواسطة بعض الخدمات؟

أخيرًا، عندما أقوم بإضافة مخالفة، هل هذه الطريقة موجودة في جهة الموظف؟شكرا للمساعدة!

Answer 1

بعد إجراء المزيد من البحث، أعتقد أن لدي الإجابة على سؤالي.

كان لدى بول ستوفيل هذا الرد المعدل قليلاً على سؤال مماثل حول لوحة رسائل DDD.استبدل كلمة "العميل" بكلمة "الموظف" وكلمة "الأمر" بكلمة "الانتهاك" وستحصل على الفكرة.

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

من وجهة نظر مجال ، يمكنك حتى التشكيك في صحة تلك المراجع (لدى العميل إشارة إلى قائمة الطلبات).كم مرة ستحتاجها بالفعل الجميع أوامر للعميل؟في بعض الأنظمة ، من المنطقي ، ولكن في حالات أخرى ، قد يقدم أحد العملاء العديد من الطلبات.من المحتمل أنك تريد طلبات للعميل بين نطاق تاريخ ، أو طلبات للعميل الذي لم يتم معالجته بعد ، أو الطلبات التي لم يتم دفعها ، وما إلى ذلك.قد يكون السيناريو الذي ستحتاج إليه جميعًا غير شائع نسبيًا.ومع ذلك ، فمن الأرجح أنه عند التعامل مع الطلب ، ستحتاج إلى معلومات العميل.لذلك في الكود ، Order.Customer.Name مفيد ، ولكن Customer.Orders[0].LineItem.SKU - ربما ليست مفيدة جدا.بالطبع ، يعتمد هذا تمامًا على مجال عملك.

بمعنى آخر، لا علاقة لتحديث العميل بتحديث الطلبات.ويمكن تصور التعامل مع الأوامر أو الانتهاكات في حالتي بشكل مستقل عن العملاء/الموظفين.

إذا كانت الانتهاكات تحتوي على أسطر تفاصيل، فسيكون سطر الانتهاك والانتهاك جزءًا من نفس التجميع لأن تغيير سطر الانتهاك من المحتمل أن يؤثر على الانتهاك.

تحرير ** التجاعيد هنا في مجال بلدي هو أن الانتهاكات ليس لها سلوك.إنها في الأساس سجلات لحدث حدث.لست متأكدا بعد من الآثار المترتبة على ذلك.

Answer 2

يقول إريك إيفان في كتابه: التصميم القائم على المجال:معالجة التعقيد في قلب البرمجيات,

AGGREGATE عبارة عن مجموعة من الكائنات المرتبطة التي نتعامل معها كوحدة لغرض تغييرات البيانات.

هناك نقطتان مهمتان هنا:

1. يجب التعامل مع هذه الكائنات على أنها "وحدة".
2. لغرض "تغيير البيانات".

أعتقد في السيناريو الخاص بك أن الموظف والانتهاك ليسا بالضرورة وحدة معًا، بينما في مثال الطلب وعنصر الطلب، فهما جزء من وحدة واحدة.

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

إجابة مختصرة جدا:

أعتقد أن كل من الموظف والانتهاك ينتميان إلى مجموعتين منفصلتين.كل من هذه الكيانات هي أيضًا جذورها الإجمالية.لذلك تحتاج إلى مستودعين:مستودع الموظفين ومستودع المخالفات.

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

var list = repository.FindAllViolationsByEmployee(someEmployee);

Answer 3

أنت تقول أن لديك كيان موظف ومخالفات وكل مخالفة ليس لها أي سلوك بحد ذاتها.مما أستطيع قراءته أعلاه، يبدو لي أنه قد يكون لديك جذرين إجماليين:

• موظف
• انتهاكات الموظف (نسميها بطاقة انتهاك الموظف أو سجلات انتهاك الموظف)

يتم تعريف "انتهاكات الموظفين" من خلال نفس معرف الموظف، وهو يحتوي على مجموعة من كائنات الانتهاك.تحصل على سلوك الموظف والمخالفات مفصولة بهذه الطريقة ولا تحصل على كيان المخالفة بدون سلوك.

سواء كان الانتهاك كيانًا أو كائن قيمة، فيجب عليك تحديده بناءً على خصائصه.

Answer 4

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

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

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

والموظف <---- يرتكب ------- ارتكبها ----> انتهاك

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

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

في العالم الوصول إلى البيانات ...

<ع> استخدام LINQ إلى SQL كمثال على ذلك، فإن DataContext تكون وحدة تحكم تعريض ضوء الكيانات العملاء والنظام. الرأي هو غير معلن، موجهة إطار نوع الجدول (أي ما يعادل الخام إلى مستودع). نلاحظ أن النظرة يحتفظ إشارة إلى وحدة تحكم الأم، ويذهب كثير من الأحيان من خلال وحدة تحكم للتحكم في كيفية / متى يحصل تتحقق طريقة العرض. وهكذا، وحدة تحكم هو موفر، مع الحرص على رسم الخرائط، والترجمة، وترطيب الجسم، وما إلى ذلك النموذج هو ثم البيانات POCOs. الى حد كبير نمط MVC نموذجي.

وعن طريق N / السبات كمثال على ذلك، فإن ISession تكون وحدة تحكم تعريض ضوء الكيانات العملاء والنظام عن طريق لsession.Enumerable (الاستعلام سلسلة) أو session.Get (كائن معرف) أو session.CreateCriteria (تشير typeof (العملاء)) قائمة ()

في العالم منطق الأعمال ...

Customer { /*...*/ }

Employee { /*...*/ }

Repository<T> : IRepository<T>
              , IEnumerable<T>
              //, IQueryable<T>, IQueryProvider //optional

{ /**/ }

BusinessController {
 Repository<Customer>  Customers { get{ /*...*/ }} //aggregate root
 Repository<Order> Orders { get{ /*...*/ }} // aggregate root
}

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

Answer 5

كنت أتساءل ماذا سيكون الاستنتاج؟

تصبح "الانتهاكات" كيانًا جذريًا.وستتم الإشارة إلى "الانتهاكات" بواسطة الكيان الجذر "للموظف".أي مستودع المخالفات <-> مستودع الموظفين

لكنك في حيرة من أمرك بشأن جعل الانتهاكات كيانًا جذريًا لأنه ليس لها سلوك.

ولكن هل يعتبر "السلوك" معيارًا للتأهل ككيان جذري؟أنا لا أعتقد ذلك.

Answer 6

وسؤال متعامد قليلا لاختبار فهم هنا، يعود إلى ترتيب ... OrderItem سبيل المثال، قد يكون هناك وحدة التحليل في النظام الذي تريد أن تبدو في OrderItems مباشرة أي الحصول على جميع orderItems لمنتج معين، أو كل أمر البنود أكبر من بعض قيمة معينة وما إلى ذلك، لا وجود الكثير من usecases من هذا القبيل والقيادة "الجذر الكلي" إلى أقصى يمكننا القول بأن OrderItem هو الجذر الكلي مختلفة في حد ذاته ؟؟

Answer 7

وهذا يعتمد. هل هناك أي تغيير / إضافة / حذف من vioation تغيير أي جزء من الموظف - على سبيل المثال أنت تخزين عدد انتهاك أو خرق الاعتماد في السنوات ال 3 الماضية ضد الموظف؟