คำถามติดแท็ก domain-model

ฉันเห็นคำนี้มากในบริบทของสถาปัตยกรรมซอฟต์แวร์ ("แบบจำลองโดเมน", "การออกแบบโดยใช้โดเมน" เป็นต้น) ฉันทำไปแล้ว แต่ได้คำจำกัดความที่แตกต่างกันมากมาย แล้วมันคืออะไร

104 domain-driven-design  terminology  domain-model  domain-objects 

เราจะวาดเส้นแบ่งระหว่างการมอบหมายและการห่อหุ้มของตรรกะทางธุรกิจได้อย่างไร สำหรับฉันดูเหมือนว่ายิ่งเรามอบหมายมากเท่าไหร่เราก็ยิ่งมีโลหิตจางมากขึ้นเท่านั้น อย่างไรก็ตามการมอบหมายยังส่งเสริมการใช้ซ้ำและเงินต้นแห้ง ดังนั้นสิ่งที่เหมาะสมในการมอบหมายและสิ่งที่ควรอยู่ในรูปแบบโดเมนของเรา ใช้ความกังวลต่อไปนี้เป็นตัวอย่าง: การอนุญาต วัตถุโดเมนควรรับผิดชอบในการรักษากฎการควบคุมการเข้าถึง (เช่นคุณสมบัติ CanEdit) หรือควรมอบให้แก่ส่วนประกอบ / บริการอื่นที่รับผิดชอบการจัดการการเข้าถึงเช่น IAuthorizationService.CanEdit (วัตถุ)? หรือมันควรจะเป็นการรวมกันของทั้งสอง? บางทีวัตถุโดเมนมีคุณสมบัติ CanEdit ซึ่งมอบหมายให้กับ IAuthorizationService ภายในเพื่อทำงานจริงหรือไม่ การตรวจสอบ การสนทนาเช่นเดียวกับข้างต้นเกี่ยวข้องกับการตรวจสอบ ใครเป็นผู้ดูแลกฎและใครรับผิดชอบในการประเมินกฎเหล่านั้น ในอีกด้านหนึ่งสถานะของวัตถุควรเป็นของวัตถุนั้นและความถูกต้องเป็นสถานะ แต่เราไม่ต้องการที่จะเขียนรหัสที่ใช้ในการประเมินกฎสำหรับทุกโดเมนวัตถุ เราสามารถใช้การสืบทอดในกรณีนี้ ... สร้างวัตถุ คลาสของโรงงานเทียบกับวิธีการของโรงงานกับ 'newing' หากเราใช้คลาสโรงงานแยกต่างหากเราสามารถแยกและห่อหุ้มตรรกะการสร้าง แต่ด้วยค่าใช้จ่ายในการเปิดสถานะของวัตถุของเราไปยังโรงงาน สิ่งนี้สามารถจัดการได้ถ้าเลเยอร์โดเมนของเราอยู่ในชุดประกอบที่แยกจากกันโดยการเปิดเผยตัวสร้างภายในที่โรงงานใช้ แต่สิ่งนี้จะกลายเป็นปัญหาหากมีหลายรูปแบบการสร้าง และถ้าโรงงานทั้งหมดกำลังเรียกผู้สร้างที่ถูกต้องจุดของการมีโรงงานคืออะไร? วิธีการในโรงงานในคลาสกำจัดปัญหาเมื่อเปิดสถานะภายในของวัตถุ แต่เนื่องจากเป็นแบบคงที่เราจึงไม่สามารถทำลายการพึ่งพาผ่านการฉีดอินเทอร์เฟซจากโรงงานเหมือนที่เราทำได้ด้วยคลาสโรงงานแยกต่างหาก วิริยะ หนึ่งอาจโต้แย้งว่าถ้าวัตถุโดเมนของเรากำลังจะเปิดเผย CanEdit ในขณะที่มอบหมายความรับผิดชอบในการดำเนินการตรวจสอบการอนุมัติให้บุคคลอื่น (IAuthorizationService) ทำไมไม่มีวิธีการบันทึกบนวัตถุโดเมนของเราที่ทำสิ่งเดียวกัน สิ่งนี้จะช่วยให้เราสามารถประเมินสถานะภายในของวัตถุเพื่อตรวจสอบว่าการดำเนินการสามารถทำได้โดยไม่ทำลาย encapsulation หรือไม่ แน่นอนมันต้องการให้เราฉีดอินสแตนซ์ที่เก็บข้อมูลลงในวัตถุโดเมนของเราซึ่งมีกลิ่นเล็กน้อยสำหรับฉันดังนั้นเราจะเพิ่มกิจกรรมโดเมนแทนและอนุญาตให้ผู้ดำเนินการดำเนินการจัดการอย่างถาวรหรือไม่ ดูว่าฉันจะไปกับอะไร Rockford Lhotka …

90 domain-driven-design  domain-model 

ฉันทำงานให้กับ บริษัท ที่โดเมนเข้าใจยากจริงๆเพราะเป็นเทคโนโลยีชั้นสูงในอุปกรณ์อิเล็กทรอนิกส์ แต่สิ่งนี้ใช้ได้กับการพัฒนาซอฟต์แวร์ใด ๆ ในโดเมนที่ซับซ้อน แอปพลิเคชันที่ฉันทำงานแสดงข้อมูลจำนวนมากแผนภูมิและตัวชี้วัดที่เข้าใจยากโดยไม่มีประสบการณ์ในโดเมน ผู้พัฒนาใช้ข้อมูลจำเพาะเพื่ออธิบายสิ่งที่ซอฟต์แวร์ต้องทำเช่นการระบุว่าแผนภูมิเฉพาะต้องแสดงตัวชี้วัดประเภทนี้และตัวชี้วัดนี้เป็นสูตรทางคณิตศาสตร์ต่อไปนี้ ด้วยวิธีนี้ผู้พัฒนาไม่เข้าใจธุรกิจจริง ๆ และเขา / เธอทำงานอะไรอยู่ นี่สามารถใช้ได้ถ้าข้อมูลจำเพาะมีรายละเอียดจริง ๆ แต่เมื่อมันไม่ใช่หรือเมื่อผู้เขียนลืมกรณีการใช้งานมันค่อนข้างยากสำหรับนักพัฒนาในการค้นหาวิธีแก้ไข ในทางกลับกันการฝึกอบรมผู้พัฒนาทุกด้านทุกธุรกิจอาจยาวและยากมาก เราควรให้ความสำคัญกับรายละเอียดทางเทคนิคมากขึ้น (แต่อย่างที่เรารู้ว่าไม่มีข้อกำหนดที่สมบูรณ์แบบ) หรือเราควรฝึกอบรมนักพัฒนาทั้งหมดให้เข้าใจโดเมนธุรกิจ? แก้ไข: โปรดจำไว้ในคำตอบของคุณว่า บริษัท สามารถใช้นักพัฒนาภายนอกและการสร้างโดเมนทั้งหมดอาจใช้เวลาประมาณ 2 สัปดาห์

52 domain-model  training 

ฉันกำลังทำงานในโครงการที่เราพยายามใช้ทั้งการออกแบบที่ขับเคลื่อนด้วยโดเมนและ REST กับสถาปัตยกรรมที่มุ่งเน้นบริการ เราไม่กังวลเกี่ยวกับการปฏิบัติตาม REST 100% อาจเป็นการดีกว่าถ้าจะบอกว่าเรากำลังพยายามสร้าง HTTP API ที่เน้นการใช้ทรัพยากร (~ ระดับ 2ของแบบจำลองวุฒิภาวะ REST ของ Richardson) แต่เรากำลังพยายามที่จะอยู่ห่างจากการใช้ RPC-รูปแบบของการร้องขอ HTTP เช่นเราพยายามที่จะดำเนินการของเรา HTTP กริยาตามRFC2616มากกว่าที่จะใช้POSTในการทำIsPostalAddressValid(...)เช่น อย่างไรก็ตามการเน้นเรื่องนี้ดูเหมือนว่าจะเป็นค่าใช้จ่ายของความพยายามของเราที่จะใช้การออกแบบที่ขับเคลื่อนด้วยโดเมน มีเพียงGET, POST, PUT, DELETEและไม่กี่วิธีที่ไม่ค่อยได้ใช้อื่น ๆ ที่เรามีแนวโน้มที่จะสร้างบริการ cruddy และบริการ cruddy มีแนวโน้มที่จะมีรูปแบบโดเมนโรคโลหิตจาง POST: รับข้อมูลตรวจสอบความถูกต้องถ่ายโอนข้อมูลไปยังข้อมูล GET: ดึงข้อมูลกลับคืนมา ไม่มีตรรกะทางธุรกิจที่แท้จริงที่นั่น นอกจากนี้เรายังใช้ข้อความ (เหตุการณ์) ระหว่างบริการและดูเหมือนว่าตรรกะทางธุรกิจส่วนใหญ่จะสร้างขึ้นมา REST และ DDD มีความตึงเครียดในบางระดับหรือไม่? (หรือฉันเข้าใจผิดบางอย่างที่นี่เราอาจทำผิดอย่างอื่นหรือไม่) เป็นไปได้ไหมที่จะสร้างโมเดลโดเมนที่แข็งแกร่งในสถาปัตยกรรมเชิงบริการขณะที่หลีกเลี่ยงการโทร HTTP สไตล์ RPC?

34 rest  domain-driven-design  domain-model 

ข้อโต้แย้งใดที่ควรพิจารณาเมื่อออกแบบระบบใหม่และต้องเก็บชื่อของบุคคลเป็นฟิลด์เดียวหรือแยกเป็นชื่อ / นามสกุล? ข้อดีสำหรับฟิลด์เดียว: UI ที่เรียบง่าย ไม่มีความกำกวมเมื่อพยายามป้อนชื่อของบุคคลที่มีชื่อยาวมาก (มักไม่ชัดเจนซึ่งเป็นนามสกุล / ชื่อ .. ) ความซับซ้อนน้อยลงเมื่อจัดการหัวเรื่อง (เช่นไม่จำเป็นต้องแยกฟิลด์เพื่อป้อน "MD" หรือ "Dr. ") ข้อดีสำหรับฟิลด์แยก: การสื่อสารส่วนบุคคลเป็นไปได้ "Dear Mr X" หรือ "Dear Julie" หากบริการเว็บที่ใช้งานต้องการชื่อ / นามสกุลแยกกันสามารถให้บริการได้อย่างง่ายดาย ทางเลือกที่ดีกว่าสำหรับอุตสาหกรรมใด ๆ ที่มีข้อกำหนดการระบุที่เข้มงวด (เช่นการแพทย์รัฐบาล ฯลฯ ) ตัวเลือกที่ปลอดภัยยิ่งขึ้นเนื่องจากคุณสามารถกลับไปใช้ทางเลือกเขตข้อมูลเดียวได้ตลอดเวลา คุณเห็นอาร์กิวเมนต์เพิ่มเติมที่ไม่ได้ระบุไว้ข้างต้นหรือไม่ อัปเดต: คำถามคืออะไรข้อโต้แย้งเพิ่มเติม (= ไม่ได้ระบุไว้ในคำถาม) สามารถแสดงรายการได้สำหรับแต่ละโซลูชัน ฉันคิดว่าการให้ความคิดเห็นแทนข้อดีและข้อเสียที่เป็นไปได้ผลักดันการอภิปรายในทางที่ผิด ผู้พัฒนาแต่ละคนจะต้องทำการตัดสินใจของเขา / เธอเกี่ยวกับปัญหานี้เป้าหมายของคำถามนี้คือการรวบรวมรายการของการขัดแย้งที่ไม่สำคัญที่สามารถประเมินได้หากจำเป็น

32 database-design  data  domain-model  data-modeling 

ฉันกำลังสร้างแบบจำลองฐานข้อมูลที่ควรใช้เป็นสิ่งจำเป็นที่ไม่มีการใช้งานทั่วไปสำหรับบริการทั้งหมดของ บริษัท เริ่มต้นเช่นบุคคลผู้ใช้บริการและข้อมูลเชิงพาณิชย์เช่นคูปองแพคเกจลายเซ็น ฯลฯ ฉันกำลังคิดเกี่ยวกับแบบจำลองเพศ ในยุคปัจจุบันนี้และด้วยกฎหมายที่แตกต่างกันในหลายประเทศเกี่ยวกับอัตลักษณ์อัตนัยฉันควรคำนึงถึงเรื่องนี้และพิจารณารูปแบบสิ่งที่บุคคลของฉันมีมากกว่าแค่ตัวเลือกชายและหญิง ? ตัวเลือกคือ: ไม่ได้กำหนดไม่ตอบรับอื่น ๆ เพศ ... หรือมาตรฐานอุตสาหกรรมอื่น ๆที่ฉันไม่รู้ ... หรือสิ่งนี้ทำให้คน LGBT ขุ่นเคืองด้วยการบอกว่าพวกเขาไม่ใช่ผู้ชายหรือผู้หญิงอย่างแท้จริง?

27 database-design  domain-model  data-modeling 

ฉันได้อ่านบทความจำนวนมากเมื่อเร็ว ๆ นี้ที่อธิบายครอบงำจิตใจดั้งเดิมเป็นกลิ่นรหัส มีประโยชน์สองประการในการหลีกเลี่ยงความหลงใหลดั้งเดิม: ทำให้โมเดลโดเมนชัดเจนยิ่งขึ้น ตัวอย่างเช่นฉันสามารถพูดคุยกับนักวิเคราะห์ธุรกิจเกี่ยวกับรหัสไปรษณีย์แทนที่จะเป็นสตริงที่มีรหัสไปรษณีย์ การตรวจสอบทั้งหมดอยู่ในที่เดียวแทนที่จะใช้ข้ามแอปพลิเคชัน มีบทความมากมายที่อธิบายเมื่อมันเป็นกลิ่นรหัส ตัวอย่างเช่นฉันสามารถเห็นประโยชน์ของการลบความหลงใหลดั้งเดิมสำหรับรหัสโพสต์เช่นนี้: public class Address { public ZipCode ZipCode { get; set; } } นี่คือตัวสร้างของรหัสไปรษณีย์: public ZipCode(string value) { // Perform regex matching to verify XXXXX or XXXXX-XXXX format _value = value; } คุณจะทำลายหลักการDRYโดยวางตรรกะการตรวจสอบความถูกต้องทุกที่ที่ใช้รหัสไปรษณีย์ อย่างไรก็ตามสิ่งที่เกี่ยวกับวัตถุต่อไปนี้: วันเดือนปีเกิด: ตรวจสอบว่ามากเกินใจและน้อยกว่าวันนี้วันที่ เงินเดือน: ตรวจสอบว่ามากกว่าหรือเท่ากับศูนย์ คุณจะสร้างวัตถุ DateOfBirth และวัตถุเงินเดือนหรือไม่ ประโยชน์คือคุณสามารถพูดคุยเกี่ยวกับพวกเขาเมื่ออธิบายรูปแบบโดเมน …

22 c#  domain-driven-design  domain-model  abstraction  modeling 

สมมติว่าเรามีระบบบันทึกงานเมื่อมีการบันทึกงานผู้ใช้จะระบุหมวดหมู่และค่าเริ่มต้นของงานเป็นสถานะ 'ดีเด่น' สมมติในกรณีนี้ว่าหมวดหมู่และสถานะจะต้องมีการใช้งานเป็นเอนทิตี ปกติฉันจะทำสิ่งนี้: แอพลิเคชันเลเยอร์: public class TaskService { //... public void Add(Guid categoryId, string description) { var category = _categoryRepository.GetById(categoryId); var status = _statusRepository.GetById(Constants.Status.OutstandingId); var task = Task.Create(category, status, description); _taskRepository.Save(task); } } Entity: public class Task { //... public static void Create(Category category, Status status, string description) { …

14 architecture  domain-driven-design  repository  domain-model  entity 

ฉันได้อ่านเกี่ยวกับการออกแบบการขับเคลื่อนด้วยโดเมนเป็นเวลาเกือบสองปีและได้รับการแนะนำแนวคิดบางอย่างเกี่ยวกับการทำงานประจำวันของฉันอย่างน้อยหรือวางแผนอย่างน้อยสำหรับสิ่งที่ฉันทำเป็นประจำในการออกแบบโดเมนที่ขับเคลื่อนได้ ข้อสรุปหนึ่งที่ฉันได้เริ่มมาโดยเฉพาะอย่างยิ่งในการตอบสนองต่อการอ่านเพิ่มเติมเกี่ยวกับการจัดหากิจกรรมและการแยกความรับผิดชอบคำสั่งแบบสอบถาม (CQRS) ที่บางทีวัตถุโดเมนมีวัตถุประสงค์ที่จะใช้สำหรับการเขียนเท่านั้น เพื่อให้ชัดเจนยิ่งขึ้นดูเหมือนว่าสิ่งที่ผู้คนแนะนำอย่างละเอียดในเอกสารส่วนใหญ่ที่ฉันได้อ่านว่าวัตถุโดเมนมีหน้าที่ในการดำเนินการ / การคำนวณโดเมนเป็นศูนย์กลางการตรวจสอบความถูกต้องและจากนั้นส่วนใหญ่จะเป็นถนน โครงสร้างพื้นฐานที่มีให้ภายในการใช้พื้นที่เก็บข้อมูล แม้ว่าฉันจะชอบความจริงที่ว่าสิ่งนี้อาจลดความซับซ้อนของโมเดลโดเมนลงอย่างมากเนื่องจากช่วยลดความรับผิดชอบในการเปิดเผยสถานะ ถ้ามันถูกต้องจริง ๆ แล้วว่าวัตถุโดเมนส่วนใหญ่จะใช้เป็นวัตถุแบบเขียนอย่างเดียวแล้วนั่นทำให้เกิดคำถามสำหรับฉันที่ฉันหวังว่าใครบางคนสามารถตอบ วิธีการหนึ่งทำการทดสอบหน่วยบนวัตถุที่มี setters หรือวิธีการที่ปรับเปลี่ยนสถานะของวัตถุ แต่ที่ให้ไม่มีส่วนต่อประสานภายนอกสาธารณะเพื่ออ่านสถานะจากเช่น getters คุณสมบัติใน C #? มันโอเคที่จะเปิดเผยสถานะเพียงเพื่อจุดประสงค์ในการทำให้วัตถุนั้นทดสอบได้หรือไม่? ผู้ใช้จะแสดงผลลัพธ์ของการคำนวณหรือการดำเนินการในโดเมนโดยไม่ต้องยืนยันพวกเขาได้อย่างไรแล้วดึงผลลัพธ์จากการเก็บข้อมูลไว้ภายนอกบริบทของโดเมน การเปิดเผยสถานะเพียงเพื่อจุดประสงค์ในการแสดงผลลัพธ์เท่านั้นหรือไม่ เป็นกฎของหัวแม่มือที่ควรได้รับทรัพย์สินเท่านั้น (รับ accessors) เป็นคนที่สามารถเขียนได้ในโดเมน? หรือกล่าวว่าคุณสมบัติที่แตกต่างกันอย่างอ่านง่ายควรเป็นสิ่งเดียวที่ควรหลีกเลี่ยงเนื่องจากมีไว้เพื่อการอ่านเท่านั้นและไม่ได้มีบทบาทที่จำเป็นในแบบจำลองโดเมนจริงหรือ วัสดุที่เกี่ยวข้อง: TDD, DDD และ Encapsulation

13 domain-driven-design  domain-model  cqrs  event-sourcing 

ฉันเข้าสู่แนวคิดเกี่ยวกับการออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD) และพบหลักการบางอย่างที่แปลกประหลาดโดยเฉพาะอย่างยิ่งเกี่ยวกับการแยกโดเมนและรูปแบบการคงอยู่ นี่คือความเข้าใจพื้นฐานของฉัน: บริการบนชั้นแอปพลิเคชัน (จัดเตรียมชุดคุณสมบัติ) ร้องขอวัตถุโดเมนจากที่เก็บที่จำเป็นต้องใช้เพื่อทำหน้าที่ของมัน การนำไปใช้อย่างเป็นรูปธรรมของที่เก็บนี้ดึงข้อมูลจากที่เก็บข้อมูลที่ถูกนำไปใช้ บริการบอกวัตถุโดเมนซึ่งสรุปทางตรรกะทางธุรกิจเพื่อดำเนินงานบางอย่างที่แก้ไขสถานะของมัน บริการบอกที่เก็บเพื่อคงออบเจ็กต์โดเมนที่ถูกแก้ไข ที่เก็บข้อมูลจำเป็นต้องแมปวัตถุโดเมนกลับไปเป็นตัวแทนที่สอดคล้องกันในการจัดเก็บ ตอนนี้จากข้อสมมติข้างต้น โฆษณา 2: ดูเหมือนว่าแบบจำลองโดเมนจะโหลดวัตถุโดเมนทั้งหมด (รวมถึงเขตข้อมูลและการอ้างอิงทั้งหมด) แม้ว่าจะไม่จำเป็นสำหรับฟังก์ชันที่ร้องขอก็ตาม การโหลดอาจไม่สามารถทำได้หากมีการอ้างอิงวัตถุโดเมนอื่นเว้นแต่คุณจะโหลดวัตถุโดเมนเหล่านั้นด้วยและวัตถุทั้งหมดที่อ้างอิงในทางกลับกันเป็นต้น การโหลด Lazy คำนึงถึงซึ่งหมายความว่าคุณเริ่มทำการค้นหาวัตถุโดเมนของคุณซึ่งควรจะเป็นความรับผิดชอบของที่เก็บในตอนแรก เมื่อพิจารณาถึงปัญหานี้ดูเหมือนว่าวิธีการโหลดวัตถุโดเมนที่ถูกต้องจะมีฟังก์ชันการโหลดเฉพาะสำหรับแต่ละกรณีการใช้งาน ฟังก์ชั่นเฉพาะเหล่านี้จะโหลดข้อมูลที่จำเป็นโดยกรณีการใช้งานที่ถูกออกแบบมาเท่านั้น นี่คือสิ่งที่น่าอึดอัดใจที่เข้ามาเล่น: อย่างแรกฉันจะต้องรักษาจำนวนมากของการโหลดฟังก์ชั่นสำหรับแต่ละการใช้งานของพื้นที่เก็บข้อมูลและวัตถุโดเมนจะจบลงในรัฐที่ไม่สมบูรณ์ที่ดำเนินการnullในสาขาของพวกเขา ในทางเทคนิคหลังควรจะไม่มีปัญหาเพราะถ้าไม่ได้โหลดค่ามันไม่ควรจะจำเป็นต้องใช้ฟังก์ชั่นที่ร้องขอมันต่อไป ถึงกระนั้นมันก็น่าอึดอัดใจและอาจเป็นอันตรายได้ โฆษณา 3: วัตถุโดเมนจะตรวจสอบข้อ จำกัด ที่ไม่ซ้ำกันอย่างไรเมื่อการก่อสร้างถ้ามันไม่มีความคิดใด ๆ ของพื้นที่เก็บข้อมูล? ตัวอย่างเช่นถ้าฉันต้องการสร้างใหม่Userด้วยหมายเลขประกันสังคมที่ไม่ซ้ำกัน (ซึ่งได้รับ) ความขัดแย้งที่เร็วที่สุดจะเกิดขึ้นเมื่อขอให้พื้นที่เก็บข้อมูลบันทึกวัตถุเฉพาะในกรณีที่มีข้อ จำกัด ที่ไม่ซ้ำกันที่กำหนดไว้ในฐานข้อมูล มิฉะนั้นฉันสามารถหา a ที่Userมีประกันสังคมที่กำหนดและรายงานข้อผิดพลาดในกรณีที่มันมีอยู่ก่อนที่จะสร้างใหม่ แต่จากนั้นการตรวจสอบข้อ จำกัด จะอาศัยอยู่ในบริการไม่ใช่ในวัตถุโดเมนที่เป็นของพวกเขา ฉันเพิ่งรู้ว่าวัตถุโดเมนได้รับอนุญาตเป็นอย่างดีในการใช้ที่เก็บ (ฉีด) สำหรับการตรวจสอบ โฆษณา 5: …

13 domain-driven-design  domain-model  persistence 

ฉันเรียนรู้เรื่องการทำความสะอาดและด้วยเหตุนี้ฉันจึงคิดใหม่อย่างมากเกี่ยวกับวิธีการออกแบบและเขียนซอฟต์แวร์ สิ่งที่ฉันยังคงต่อสู้ด้วยมีไว้สำหรับกฎเกณฑ์ทางธุรกิจเช่น "ในการอัปเดตการบันทึกบางรายการก่อนอื่นโหลดรายการทั้งหมดที่ฉันได้รับอนุญาตให้ดู / แก้ไข ฯลฯ ยืนยันว่ารายการนี้อยู่ในรายการ และหมวดหมู่รายการไม่ได้ถูกล็อกจากการใช้งาน (และกฎอื่น ๆ ฯลฯ ) ".. เนื่องจากเป็นกฎธุรกิจ (ซับซ้อน แต่ไม่ผิดปรกติ) ดังนั้นจึงควรจัดการในโดเมนแอปพลิเคชันแทนที่จะผลักดันตรรกะทางธุรกิจลงใน ชั้น db / การคงอยู่ อย่างไรก็ตามดูเหมือนว่าสำหรับฉันที่จะตรวจสอบเงื่อนไขเหล่านี้ได้อย่างมีประสิทธิภาพมันมักจะได้รับการจัดการที่ดีที่สุดกับแบบสอบถาม DB ที่สร้างขึ้นมาอย่างดีแทนที่จะโหลดข้อมูลทั้งหมดลงในโดเมนแอปพลิเคชัน ... หากไม่มีการปรับให้เหมาะสมก่อนเวลาอันควรแนวทางที่แนะนำหรือบทความบ็อบลุงจัดการกับคำถามนี้คืออะไร หรือเขาจะพูดว่า "ตรวจสอบในโดเมนจนกว่ามันจะกลายเป็นปัญหา" ?? ฉันกำลังดิ้นรนเพื่อค้นหาตัวอย่าง / ตัวอย่างที่ดีสำหรับสิ่งอื่นใดนอกเหนือจากกรณีพื้นฐานที่สุดของการใช้งาน ปรับปรุง: สวัสดีทุกคนขอบคุณสำหรับการตอบกลับ ฉันควรจะชัดเจนกว่าฉันเขียนซอฟต์แวร์ (ส่วนใหญ่เป็นแอปพลิเคชันเว็บ) เป็นเวลานานและมีประสบการณ์แล้วและเห็นด้วยกับทุกหัวข้อที่คุณอธิบายร่วมกัน (ตรวจสอบโดยแบ็กเอนด์ไม่เชื่อถือข้อมูลลูกค้าโดยทั่วไป ไล่ล่าประสิทธิภาพดิบเมื่อจำเป็นเท่านั้น แต่รับทราบจุดแข็งของเครื่องมือ db เมื่อมีให้ใช้ ฯลฯ ) และได้ผ่านวงจรการเรียนรู้ของนักพัฒนาของ "โยนทั้งหมดเข้าด้วยกัน" เพื่อ "สร้างตัวควบคุมไขมันยักษ์ด้วยแอปพลิเคชัน N-tiers" และตอนนี้ชอบและตรวจสอบสไตล์ความรับผิดชอบที่สะอาด …

13 clean-code  domain-model  validation  business-rules 

Persistence Ignoranceเป็นแอพพลิเคชั่นของหลักการความรับผิดชอบเดี่ยวซึ่งในทางปฏิบัติหมายความว่า Domain Objects ( DO ) ไม่ควรมีรหัสที่เกี่ยวข้องกับการคงอยู่ แต่ควรจะมีตรรกะของโดเมนเท่านั้น a) ฉันถือว่านี่หมายความว่ารหัสที่ติดต่อเลเยอร์ที่ต่ำกว่า (เช่นชั้นที่มีอยู่) อยู่นอกโมเดลโดเมนในคลาสอื่น ( OC ) ของเลเยอร์ตรรกะทางธุรกิจหรือไม่ b) หากการสันนิษฐานของฉันภายใต้a)ถูกต้องดังนั้นDOพูดว่าCustomerไม่มีวิธีการเช่นGetCustomersหรือGetCustomerByID? c) หากสมมุติฐานของฉันภายใต้a)และb)ถูกต้องและสมมติว่าCustomerวัตถุโดเมนใช้การโหลดแบบขี้เกียจสำหรับคุณสมบัติบางอย่างนั้นCustomerตรรกะภายในของบางจุดจะต้องติดต่อOCซึ่งจะดึงข้อมูลที่ได้รับการแก้ไข แต่ถ้าCustomerต้องการติดต่อOCเพื่อรับข้อมูลที่ถูกหักล้างเราไม่สามารถอ้างสิทธิ์ได้จริงๆว่า Domain Objects ไม่มีตรรกะที่เกี่ยวข้องกับการคงอยู่หรือไม่! ขอบคุณ ตอบกลับไปยัง jkohlhepp 1) ผมถือว่าOrderProviderและCustomerProviderชั้นเรียนที่มีอยู่ภายในชั้นตรรกะทางธุรกิจ? 2) ฉันรวบรวมจากคำตอบของคุณว่าสมมติฐานของฉันภายใต้ข)ถูกต้องหรือไม่ 3) ... ฉันจะตรวจสอบเพื่อดูว่าฟิลด์คำสั่งซื้อส่วนตัวบางส่วนมีการเติมข้อมูลหรือไม่หรือไม่ ถ้ามันเป็นโมฆะ ... แต่เท่าที่ฉันสามารถบอกได้ทันทีที่รหัสโดเมนจำเป็นต้องตรวจสอบว่าorderมีการเติมข้อมูลในฟิลด์ส่วนตัวหรือไม่และถ้าไม่ติดต่อ OrderProvider เรากำลังละเมิดหลักการPIอยู่แล้ว!

12 design-patterns  domain-driven-design  domain-model  persistence 

ในตรรกะทางธุรกิจของเราบางครั้งเรามีวิธีการที่กำหนดไว้ดังนี้: User.ResetCourse(Course courseToReset) ปัญหาคือทั้งผู้ใช้และหลักสูตรเป็นวัตถุพร็อกซี Entity Framework ซึ่งหมายความว่าเมื่อเราเข้าสู่คุณสมบัติการนำทางทั้งผู้ใช้หรือหลักสูตรมันสามารถทำให้เกิดความนิยมอย่างมากในฐานข้อมูลเพราะวัตถุเหล่านั้นไม่ได้เป็น IQueryable ดังนั้นจึงวนซ้ำผ่านพวกเขาตามปกติ เพื่อแก้ปัญหานี้เราเปลี่ยนลายเซ็นเป็น: User.ResetCourse(MyDBContext db, Course courseToReset) ซึ่งหมายความว่าเราสามารถสอบถามฐานข้อมูลโดยตรงเพื่อทำการเปลี่ยนแปลงที่เราต้องการอย่างมีประสิทธิภาพ แต่การส่งบริบทฐานข้อมูลไปยังวัตถุทางธุรกิจดูเหมือนจะผิดพลาด หลังจากนั้นเราย้ายไปยังชั้นบริการที่ให้ผู้ใช้ซึ่งหมายความว่าเรามีสิ่งที่ชอบ: CourseService.ResetForUser(Course courseToReset, User forUser) บริการนี้มีการอ้างอิงถึง DBContext ที่ถูกสร้าง แต่ตอนนี้วัตถุธุรกิจของเราเป็นเพียงถุงข้อมูลที่ไม่มีพฤติกรรม (เช่นรุ่น Anemic Domain Model) เราจะหลีกเลี่ยงสิ่งนี้ได้อย่างไร

11 c#  entity-framework  domain-model  business-logic 

คำถามแบบสั้น มันอยู่ในแนวปฏิบัติที่ดีที่สุดของ DDD และ OOP ในการฉีดบริการกับการเรียกเมธอดเอนทิตีหรือไม่? ตัวอย่างรูปแบบยาว สมมติว่าเรามีกรณี Order-LineItems แบบคลาสสิกใน DDD ที่เรามี Domain Entity ชื่อ Order ซึ่งยังทำหน้าที่เป็น Aggregate Root และ Entity นั้นไม่เพียง แต่ประกอบไปด้วย Value Objects แต่ยังเป็นคอลเลกชันของรายการโฆษณา หน่วยงาน สมมติว่าเราต้องการไวยากรณ์ที่คล่องแคล่วในแอปพลิเคชันของเราเพื่อให้เราสามารถทำสิ่งนี้ (สังเกตไวยากรณ์ในบรรทัดที่ 2 ซึ่งเราเรียกgetLineItemsเมธอด) $order = $orderService->getOrderByID($orderID); foreach($order->getLineItems($orderService) as $lineItem) { ... } เราไม่ต้องการฉีด LineItemRepository ใด ๆ ลงใน OrderEntity เนื่องจากเป็นการละเมิดหลักการหลายอย่างที่ฉันสามารถนึกได้ แต่ความคล่องแคล่วของวากยสัมพันธ์เป็นสิ่งที่เราต้องการจริงๆเพราะมันง่ายต่อการอ่านและบำรุงรักษารวมถึงการทดสอบ พิจารณาโค้ดต่อไปนี้โดยสังเกตวิธีgetLineItemsในOrderEntity: interface …

11 object-oriented  php  domain-driven-design  domain-model  lazy-initialization 

คุณกำลังสร้างระบบที่ติดตาม บริษัท บริษัท เหล่านั้นมีผู้ติดต่อ ผู้ติดต่อเหล่านั้นมักเป็นผู้เชี่ยวชาญที่ตอบเฉพาะคำถามบางประเภทเท่านั้นเช่นการเรียกเก็บเงิน / ชำระเงินการขายการสั่งซื้อและการสนับสนุนลูกค้า การใช้การออกแบบโดเมนขับเคลื่อนและสถาปัตยกรรมหัวหอมฉันได้ทำแบบจำลองนี้ด้วยประเภทต่อไปนี้: บริษัท มีผู้ติดต่อ ติดต่อ มีประเภทการติดต่อ ContactType (enum) CompanyRepository (อินเตอร์เฟส) EFCompanyRepository (กำหนดไว้ในแอสเซมบลีภายนอกใช้ EntityFramework ดำเนินการ CompanyRepository) ทีมของเรามีความเห็นแยกกันเกี่ยวกับวิธีการสร้างแบบจำลองฐานข้อมูลสำหรับแอปพลิเคชันนี้ ด้าน A: DDDers แบบ Lean: เป็นหน้าที่ของโดเมนในการกำหนดว่า ContactTypes ใดที่ถูกต้องสำหรับที่ติดต่อ การเพิ่มตารางไปยังฐานข้อมูลเพื่อตรวจสอบว่า ContactTypes ที่ไม่รู้จักไม่ได้ถูกบันทึกเป็นสัญลักษณ์ของโดเมนที่รั่ว มันกระจายตรรกะออกไปไกลเกินไป การเพิ่มตารางคงที่ในฐานข้อมูลและรหัสที่เกี่ยวข้องนั้นสิ้นเปลือง ในแอปพลิเคชั่นนี้ฐานข้อมูลแก้ปัญหาหนึ่ง: ยืนยันสิ่งนั้นและส่งคืนให้ฉัน การเขียนตารางพิเศษและรหัส CRUD ที่เกี่ยวข้องนั้นสิ้นเปลือง การเปลี่ยนกลยุทธ์เพื่อการคงอยู่นั้นง่ายที่สุดเท่าที่จะทำได้ มีแนวโน้มที่จะเปลี่ยนกฎธุรกิจ ถ้าฉันตัดสินใจว่า SQL Server มีค่าใช้จ่ายมากเกินไปฉันไม่ต้องการสร้างการตรวจสอบความถูกต้องทั้งหมดที่ฉันใส่ไว้ในสคีมาใหม่อีกครั้ง ด้าน B: นักอนุรักษนิยม [นั่นอาจไม่ใช่ชื่อที่ยุติธรรม …

10 domain-driven-design  domain-model  onion-architecture