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

ฉันเป็นนักพัฒนารุ่นน้องในรุ่นพี่และกำลังดิ้นรนมากกับการเข้าใจความคิดเหตุผล ฉันกำลังอ่านการออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD) และไม่เข้าใจว่าทำไมเราต้องสร้างคลาสจำนวนมาก ถ้าเราทำตามวิธีการออกแบบซอฟต์แวร์เราจะจบด้วยชั้นเรียน 20-30 ชั้นซึ่งสามารถแทนที่ได้ด้วยไฟล์มากที่สุดสองไฟล์และฟังก์ชั่น 3-4 อย่าง ใช่มันอาจยุ่งเหยิง แต่มันสามารถดูแลและอ่านได้มากกว่า เมื่อใดก็ตามที่ฉันต้องการดูว่าบางอย่างEntityTransformationServiceImplทำอะไรฉันต้องติดตามคลาสอินเทอร์เฟซการเรียกใช้ฟังก์ชันการสร้างการสร้างและอื่น ๆ มากมาย คณิตศาสตร์ง่าย ๆ : รหัสจำลอง 60 บรรทัดเทียบกับ 10 คลาส X 10 (สมมติว่าเรามี logics ที่แตกต่างกันโดยสิ้นเชิง) = 600 บรรทัดของรหัสยุ่งกับ 100 ชั้นเรียน + อีกมากมายที่จะรวมและจัดการ อย่าลืมเพิ่มการฉีดพึ่งพา อ่านรหัสยุ่ง 600 เส้น = หนึ่งวัน 100 คลาส = หนึ่งสัปดาห์ยังคงลืมว่าหนึ่งจะทำอะไรเมื่อ ทุกคนบอกว่าง่ายต่อการบำรุงรักษา แต่เพื่ออะไร ทุกครั้งที่คุณเพิ่มฟังก์ชันการทำงานใหม่คุณจะเพิ่มคลาสอีกห้าคลาสด้วยโรงงานหน่วยงานบริการและค่านิยม ฉันรู้สึกว่ารหัสประเภทนี้เคลื่อนที่ช้ากว่ารหัสที่ยุ่งเหยิงมาก สมมติว่าถ้าคุณเขียนรหัสยุ่ง 50K …

209 design-patterns  domain-driven-design  source-code 

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

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 

ในการอภิปรายเกี่ยวกับโมเดลโดเมน Rich and Anemic อินเทอร์เน็ตเต็มไปด้วยคำแนะนำทางปรัชญา แต่ย่อมาจากตัวอย่างที่เชื่อถือได้ วัตถุประสงค์ของคำถามนี้คือการหาแนวทางที่ชัดเจนและตัวอย่างที่เป็นรูปธรรมของโมเดลการออกแบบที่ขับเคลื่อนด้วยโดเมนที่เหมาะสม (นึกคิดใน C #.) สำหรับตัวอย่างในโลกแห่งความจริงการใช้ DDD นี้ดูเหมือนจะผิด: โดเมน WorkItem รุ่นด้านล่างไม่มีอะไรนอกจากถุงคุณสมบัติซึ่ง Entity Framework ใช้สำหรับฐานข้อมูลรหัสแรก ต่อฟาวเลอร์ก็เป็นโรคโลหิตจาง เห็นได้ชัดว่าชั้น WorkItemService เป็นความเข้าใจผิดทั่วไปของบริการโดเมน มันมีพฤติกรรม / ตรรกะทางธุรกิจทั้งหมดสำหรับ WorkItem ต่อ Yemelyanov และคนอื่น ๆ ก็เป็นขั้นตอน (หน้า 6) ดังนั้นถ้าด้านล่างผิดฉันจะทำให้ถูกต้องได้อย่างไร พฤติกรรมเช่นAddStatusUpdateหรือCheckoutควรเป็นของคลาส WorkItem ที่ถูกต้องหรือไม่ แบบจำลอง WorkItem ควรพึ่งพาอะไร? public class WorkItemService : IWorkItemService { private IUnitOfWorkFactory _unitOfWorkFactory; …

84 c#  object-oriented  object-oriented-design  domain-driven-design 

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

64 spoken-languages  domain-driven-design 

ฉันต้องการที่จะรู้ว่าสิ่งที่แตกต่างชั้นบริการจากระดับยูทิลิตี้หรือชั้นผู้ช่วย? ชั้นเรียนที่มีวิธีการพื้นฐานเรียก dao เป็นบริการหรือไม่ การใช้คลาส Helper ไม่เป็นการละเมิด SRP หรือไม่

61 java  design  domain-driven-design 

เมื่อนานมาแล้วเราได้เพิ่มคุณสมบัติที่ผู้ใช้ของเราสามารถ "ยอมรับ" ภาพหลังจากที่เพิ่มเข้าไปในคิวเวิร์กโฟลว์ ปรากฎว่าเราใช้คำผิดและผู้ใช้ "อนุมัติ" รูปภาพ การเปลี่ยนยอมรับเป็นอนุมัติบนอินเทอร์เฟซของเรานั้นง่ายดายเพียงแค่เปลี่ยนคำเดียว แต่เราตั้งโปรแกรมเลเยอร์ทั้งหมดด้วยคำว่า "accept" จากชื่อคลาส CSS ไปจนถึงค่าฐานข้อมูล คลาส CSS ที่เปลี่ยนเป็นปุ่มสีเขียว: ".accepted"; เมธอดโมเดลที่ตรวจสอบและผูกแอ็ตทริบิวต์คลาสบนโหนด DOM: "isAccepted"; แอตทริบิวต์สถานะ JavaScript: อาร์เรย์ที่มี "unreviewed", "ยอมรับ" และ "เผยแพร่"; คอลัมน์สถานะ Mysql: ENUM ที่มี "ไม่ได้ตรวจสอบ", "ยอมรับ" และ "เผยแพร่"; ชื่อทดสอบ เป็นเรื่องเล็กน้อย (โดยเฉพาะเมื่อคุณมีการทดสอบ) เพื่อแทนที่การยอมรับส่วนใหญ่ที่จะอนุมัติ ยากกว่าเล็กน้อยคือการโยกย้ายข้อมูลโดยเฉพาะอย่างยิ่งเนื่องจากต้องมีการซิงโครไนซ์กับการปรับใช้ คดีเฉพาะเรื่องนี้เรียบง่าย แต่ฉันเคยเจอคดีที่คล้ายกัน แต่มีความซับซ้อนมากกว่าในระหว่างการทำงาน เมื่อไฟล์ถูกเปลี่ยนชื่อและการปรับใช้เกิดขึ้นในเซิร์ฟเวอร์หลายสิบเครื่องหรือเมื่อแคชพร็อกซี memcached และ mysql เกี่ยวข้อง การปล่อย "ยอมรับ" ในทุก …

50 refactoring  domain-driven-design 

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

46 architecture  domain-driven-design 

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

44 design  domain-driven-design 

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

44 mvc  architecture  domain-driven-design  reporting  data-warehouse 

ฉันกำลังดำน้ำในการออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD) และในขณะที่ฉันไปลึกมากขึ้นในนั้นมีบางสิ่งที่ฉันไม่ได้รับ ตามที่ฉันเข้าใจแล้วประเด็นหลักคือการแยก Domain Logic (Business Logic) จาก Infrastructure (DB, File System ฯลฯ ) สิ่งที่ฉันสงสัยคือจะเกิดอะไรขึ้นเมื่อฉันมีข้อความค้นหาที่ซับซ้อนมากเช่นแบบสอบถามการคำนวณทรัพยากรวัสดุ ในประเภทของแบบสอบถามที่คุณทำงานกับการดำเนินการชุดใหญ่ประเภทของสิ่งที่ SQL ได้รับการออกแบบมาสำหรับ ทำการคำนวณเหล่านั้นภายใน Domain Layer และทำงานกับชุดจำนวนมากในนั้นก็เหมือนกับการทิ้งเทคโนโลยี SQL การคำนวณเหล่านี้ในโครงสร้างพื้นฐานไม่สามารถเกิดขึ้นได้เช่นกันเพราะรูปแบบ DDD ช่วยให้สามารถเปลี่ยนแปลงโครงสร้างพื้นฐานได้โดยไม่ต้องเปลี่ยน Domain Layer และรู้ว่า MongoDB ไม่มีความสามารถเช่น SQL Server ที่ไม่สามารถเกิดขึ้นได้ นั่นเป็นข้อผิดพลาดของรูปแบบ DDD หรือไม่?

43 domain-driven-design  database-design  sql  database-development 

เมื่อทำงานผ่านหนังสือ "การใช้การออกแบบโดเมนขับเคลื่อน" โดย Vaughn Vernon ฉันไม่สามารถเข้าใจอย่างถ่องแท้ว่าบริบทที่แท้จริงนั้นเป็นอย่างไร หนังสือกำหนดบริบทที่มีขอบเขตว่า "ขอบเขตความคิดที่สามารถใช้โมเดลโดเมนได้มีภาษา Ubiquitous ที่พูดโดยทีมงาน คำจำกัดความนี้จะทำให้ดูเหมือนกับบริบทที่ล้อมรอบคือรูปแบบและภาษาของโดเมนย่อยซึ่งโดเมนย่อยนั้นอาจเป็นโดเมนหลัก (ซึ่งดูเหมือนว่าควรจะเรียกว่า "โดเมนย่อยหลัก" แต่นั่นคือ การสนทนาอื่น ... ) สิ่งนี้ยังทำให้เกิดความคลุมเครือเกี่ยวกับบริบทที่ จำกัด ไว้ มันคือการจัดกลุ่มของหนึ่งหรือมากกว่าโดเมนย่อย? หากมีโดเมนย่อยเพียงโดเมนเดียวที่สอดคล้องกับบริบทที่ถูกล้อมบริบทบริบทที่บอกเราคืออะไร? อย่างไรก็ตามบทที่ 3 ของหนังสือเล่มเดียวกันหมายถึงเทคนิคการรวมระหว่างบริบทที่ล้อมรอบ อย่างไรก็ตามสิ่งนี้ดูเหมือนจะบ่งบอกว่าบริบทที่ล้อมรอบนั้นเป็นระบบซอฟต์แวร์หรือสิ่งประดิษฐ์ที่มีความหลากหลาย มาร์ตินฟาวเลอร์กล่าวถึงแนวคิดบริบทที่ล้อมรอบสั้น ๆ ( http://martinfowler.com/bliki/BoundedContext.html ) แต่ไม่ได้ชี้แจงปัญหาอย่างแท้จริง ในตอนท้ายของวันที่สิ่งที่เป็นบริบทที่ล้อมรอบ? มันคือการจัดกลุ่มของโดเมนย่อยหรือไม่? รูปแบบและภาษาสำหรับโดเมนย่อยหรือไม่ การใช้งานของโดเมนย่อยหรือไม่? ดูเหมือนจะยากที่จะเข้าใจวิธีแยกย่อยพื้นที่ปัญหาในชีวิตจริงออกเป็นบริบทที่ล้อมรอบ

40 domain-driven-design 

ฉันกำลังดำน้ำในการออกแบบการขับเคลื่อนด้วยโดเมนและแนวคิดบางอย่างที่ฉันกำลังเผชิญทำให้รู้สึกมากบนพื้นผิว แต่เมื่อฉันคิดเกี่ยวกับพวกเขามากขึ้นฉันต้องสงสัยว่ามันเป็นความคิดที่ดีจริงๆ ยกตัวอย่างเช่นแนวคิดของ Aggregates คุณสร้างโดเมนเล็ก ๆ ของการเป็นเจ้าของเพื่อให้คุณไม่ต้องจัดการกับรูปแบบโดเมนทั้งหมด อย่างไรก็ตามเมื่อฉันคิดถึงสิ่งนี้ในบริบทของเว็บแอปเรามักจะกดปุ่มฐานข้อมูลเพื่อดึงข้อมูลย่อย ๆ ตัวอย่างเช่นหน้าเว็บอาจแสดงรายการจำนวนการสั่งซื้อเท่านั้นโดยมีลิงก์ให้คลิกเพื่อเปิดคำสั่งซื้อและดูรหัสคำสั่งซื้อ ถ้าผมทำความเข้าใจขันธ์ขวาฉันมักจะใช้รูปแบบการเก็บข้อมูลที่จะกลับ OrderAggregate ว่าจะมีสมาชิกGetAll, GetByID, และDelete Saveตกลงนั่นฟังดูดี แต่... ถ้าฉันโทร GetAll เพื่อแสดงรายการคำสั่งซื้อทั้งหมดของฉันดูเหมือนว่ารูปแบบนี้จะต้องมีการส่งคืนรายการข้อมูลรวมทั้งหมดคำสั่งซื้อที่สมบูรณ์คำสั่งซื้อบรรทัด ฯลฯ ... เมื่อฉันต้องการชุดย่อยของข้อมูลนั้นเพียงเล็กน้อย (เพียงแค่ข้อมูลส่วนหัว) ฉันพลาดอะไรไปรึเปล่า? หรือมีการเพิ่มประสิทธิภาพในระดับหนึ่งที่คุณจะใช้ที่นี่ ฉันไม่สามารถจินตนาการได้ว่าใครก็ตามจะสนับสนุนให้ส่งคืนข้อมูลทั้งหมดเมื่อคุณไม่ต้องการ แน่นอนหนึ่งสามารถสร้างวิธีการในพื้นที่เก็บข้อมูลของคุณชอบGetOrderHeadersแต่ที่ดูเหมือนจะเอาชนะวัตถุประสงค์ของการใช้รูปแบบเช่นพื้นที่เก็บข้อมูลในสถานที่แรก ใครช่วยอธิบายเรื่องนี้ให้ฉันได้บ้าง แก้ไข: หลังจากการวิจัยมากขึ้นฉันคิดว่าการปลดการเชื่อมต่อที่นี่คือรูปแบบพื้นที่เก็บข้อมูลบริสุทธิ์แตกต่างจากสิ่งที่คนส่วนใหญ่คิดว่าเป็นพื้นที่เก็บข้อมูล ฟาวเลอร์กำหนดที่เก็บเป็นที่เก็บข้อมูลที่ใช้ความหมายของการรวบรวมและโดยทั่วไปจะถูกเก็บไว้ในหน่วยความจำ นี่หมายถึงการสร้างกราฟวัตถุทั้งหมด อีแวนส์เปลี่ยนแปลงที่เก็บเพื่อรวม Agotsate Roots และทำให้ที่เก็บถูกตัดเพื่อสนับสนุนวัตถุใน Aggregate เท่านั้น คนส่วนใหญ่มักนึกถึงที่เก็บข้อมูลว่าเป็น Data Data Objects ที่ซึ่งคุณเพิ่งสร้างวิธีการรับข้อมูลที่คุณต้องการ ดูเหมือนจะไม่ได้มีเจตนาตามที่อธิบายไว้ในรูปแบบของสถาปัตยกรรมแอปพลิเคชัน Enterprise ของ Fowler ยังมีคนอื่นคิดว่าที่เก็บเป็นนามธรรมที่เรียบง่ายใช้เป็นหลักในการทดสอบและการเยาะเย้ยง่ายขึ้นหรือเพื่อแยกความคงทนจากส่วนที่เหลือของระบบ ฉันเดาคำตอบว่านี่เป็นแนวคิดที่ซับซ้อนกว่าที่ฉันคิดไว้ก่อน

40 performance  domain-driven-design  aggregate 

ฉันกำลังค้นคว้ารูปแบบสถาปัตยกรรมสำหรับแอปพลิเคชันที่ฉันกำลังพัฒนาและวิธีการบริการไมโครดูเหมือนว่าจะเป็นทางเลือกที่ดี แต่ฉันไม่แน่ใจว่าจะจัดการกับการโต้ตอบระหว่างบริการได้อย่างไร แอปพลิเคชั่นจะเกี่ยวข้องกับผู้ใช้โปรไฟล์ที่ผู้ใช้เป็นเจ้าของรูปถ่ายและแท็กที่แสดงโปรไฟล์หนึ่งถึงหลายโปรไฟล์ในภาพถ่าย อาจเป็นไปได้ว่ามีวิธีการส่งคืนรูปภาพที่อัพโหลดโดยผู้ใช้ส่งคืนรูปภาพที่มีโปรไฟล์ที่ติดแท็ก ฯลฯ นี่คือการแทงครั้งแรกของฉันในการออกแบบสถาปัตยกรรมที่ใช้ microservice และฉันมาจากรูปแบบโดเมนเสาหินที่ได้แรงบันดาลใจจากประวัติศาสตร์ ในโลกนั้นผู้ควบคุมจะต่อวัตถุโดเมนเหล่านี้เข้าด้วยกัน แต่ฉันมีปัญหาในการคาดหัวว่ามันจะทำงานได้อย่างไรในแบบไมโครวินาที

39 architecture  web-applications  domain-driven-design  microservices 

ฉันยังคงมองหาแนวปฏิบัติที่ดีที่สุดสำหรับการตรวจสอบความถูกต้องของแบบจำลองโดเมน เป็นสิ่งที่ดีที่จะนำการตรวจสอบในตัวสร้างของรูปแบบโดเมน? ตัวอย่างการตรวจสอบความถูกต้องของโมเดลโดเมนของฉันมีดังนี้: public class Order { private readonly List<OrderLine> _lineItems; public virtual Customer Customer { get; private set; } public virtual DateTime OrderDate { get; private set; } public virtual decimal OrderTotal { get; private set; } public Order (Customer customer) { if (customer == null) throw new ArgumentException("Customer …

38 design-patterns  domain-driven-design  validation