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

ฉันกำลังดิ้นรนเล็กน้อยกับการอ้างอิงระหว่างมวลรวม สมมติรวมมีการอ้างอิงถึงการรวมCar อ้างอิงนี้จะได้รับการสร้างแบบจำลองโดยมีDriverCar.driverId ตอนนี้ปัญหาของฉันคือไกลแค่ไหนฉันควรจะไปในการตรวจสอบการสร้างที่รวมอยู่ในCar CarFactoryฉันควรจะเชื่อหรือไม่ว่าการส่งผ่านDriverIdหมายถึงที่มีอยู่ Driverหรือฉันควรตรวจสอบค่าคงที่หรือไม่ สำหรับการตรวจสอบฉันเห็นความเป็นไปได้สองประการ: ฉันสามารถเปลี่ยนลายเซ็นของโรงงานรถยนต์เพื่อยอมรับเอนทิตีของคนขับทั้งหมด จากนั้นโรงงานก็จะเลือกรหัสจากเอนทิตีนั้นและสร้างรถด้วย ที่นี่ค่าคงที่มีการตรวจสอบโดยปริยาย ฉันจะมีการอ้างอิงของDriverRepositoryในและชัดเจนโทรCarFactorydriverRepository.exists(driverId) แต่ตอนนี้ฉันสงสัยว่าการตรวจสอบไม่แปรปรวนมากเกินไปใช่ไหม ฉันสามารถจินตนาการได้ว่ามวลรวมเหล่านั้นอาจอาศัยอยู่ในบริบทที่มีขอบเขตแยกกันและตอนนี้ฉันจะทำให้มลภาวะทางรถยนต์ของ BC กับการพึ่งพาใน DriverRepository หรือเอนทิตีของผู้ขับขี่ของไดรเวอร์ BC นอกจากนี้ถ้าฉันจะพูดคุยกับผู้เชี่ยวชาญในโดเมนพวกเขาจะไม่ถามถึงความถูกต้องของข้อมูลอ้างอิงดังกล่าว ฉันรู้สึกว่าฉันทำให้รูปแบบโดเมนของฉันสกปรกด้วยความกังวลที่ไม่เกี่ยวข้อง แต่แล้วอีกครั้งในบางจุดการป้อนข้อมูลผู้ใช้ควรได้รับการตรวจสอบ

11 domain-driven-design 

ฉันมีแอพพลิเคชั่น ASP.NET MVC ที่ใช้บริการสอบถามเพื่อรับข้อมูลและบริการคำสั่งเพื่อส่งคำสั่ง คำถามของฉันเกี่ยวกับส่วนคำสั่ง หากมีการร้องขอเข้ามาบริการคำสั่งจะใช้โปรแกรมเลือกจ่ายงานคำสั่งที่จะกำหนดเส้นทางคำสั่งไปยังตัวจัดการคำสั่งที่กำหนดไว้ ตัวจัดการคำสั่งนี้ตรวจสอบความถูกต้องของ comand ก่อนและหากทุกอย่างเป็นที่ยอมรับก็จะดำเนินการคำสั่ง ตัวอย่างที่เป็นรูปธรรม: AddCommentToArticleCommandHandler ได้รับ AddCommentToArticleCommand ซึ่งมี ArticleId, CommentText และ EmailAddress ครั้งแรก; การตรวจสอบจะต้องเกิดขึ้นเช่น: - ตรวจสอบว่ามีบทความอยู่หรือไม่ - ตรวจสอบว่าบทความไม่ได้ปิดอยู่หรือไม่ - ตรวจสอบว่ามีการกรอกข้อความแสดงความคิดเห็นและระหว่าง 20 ถึง 500 อักขระหรือไม่ - ตรวจสอบว่ากรอกอีเมลแล้วหรือไม่ ฉันสงสัยว่าจะใช้การตรวจสอบนี้ที่ไหน 1 / ในตัวจัดการคำสั่งเอง แต่จะไม่สามารถนำกลับมาใช้ใหม่ได้ในตัวจัดการคำสั่งอื่น 2 / ในนิติบุคคลโดเมน แต่เป็นนิติบุคคลที่โดเมนไม่ทราบเกี่ยวกับที่เก็บหรือบริการจึงไม่สามารถทำการตรวจสอบที่จำเป็น (ไม่สามารถตรวจสอบว่ามีบทความ) แต่ในทางกลับกันหากเอนทิตีไม่มีตรรกะมากกว่าจะกลายเป็นที่เก็บข้อมูลอย่างง่ายซึ่งไม่เป็นไปตามหลักการ DDD 3 / ตัวจัดการคำสั่งใช้ตัวตรวจสอบความถูกต้องเพื่อให้การตรวจสอบสามารถนำกลับมาใช้ในตัวจัดการคำสั่งอื่น ๆ 4 / …

11 c#  architecture  domain-driven-design  validation  cqrs 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา รูปแบบของโดเมนโลหิตจางถูกวิพากษ์วิจารณ์เมื่อนานมาแล้วโดยEvans และ Fowlerเนื่องจากเห็นได้ชัดว่ามันขัดกับหลักการเชิงวัตถุ ฯลฯ ชุมชน DDD นั้นสอดคล้องกับข้อความนี้อย่างชัดเจน อย่างไรก็ตามในช่วงไม่กี่ปีที่ผ่านมามีเสียงไม่เห็นด้วยที่อ้างว่ามันไม่ได้เป็นปฏิปักษ์เลยและเป็นตัวอย่างของการปฏิบัติตามหลักการของโซลิด ฉันใช้งาน Spring Framework มาหลายปีแล้ว ทุกโครงการในทุก บริษัท มีชั้นบริการที่มีตรรกะทางธุรกิจอยู่เสมอโดยใช้แหล่งเก็บข้อมูลที่ทำงานกับโมเดลโลหิตจาง (เอนทิตี JPA) นอกจากนี้ตัวอย่างส่วนใหญ่แม้แต่คนที่เป็นทางการจากพวก Spring ก็แสดงวิธีการทำงานนี้ คำถามของฉันคือ: โมเดลโดเมนโลหิตจางยังถือว่าเป็น antipattern หรือไม่? เราทุกคนทำสิ่งต่าง ๆ (เกี่ยวกับ DDD) ผิดหรือเปล่า? คุณไม่คิดว่าการมีโมเดล Rich Domain ละเมิดหลักการของ SOLID หรือไม่

11 domain-driven-design  spring  anti-patterns 

ฉันต้องการเขียนแอปพลิเคชันเช่นอีคอมเมิร์ซ และคุณรู้ว่าในผลิตภัณฑ์แอปพลิเคชันที่คล้ายกันอาจมีคุณสมบัติและคุณสมบัติที่แตกต่างกัน เพื่อจำลองโอกาสดังกล่าวฉันได้สร้างเอนทิตีโมเดลโดเมนต่อไปนี้: หมวดหมู่ - นี่คือสิ่งที่ "อิเล็กทรอนิกส์> сomputers" เช่นประเภทของผลิตภัณฑ์ С Categories มีรายการคุณสมบัติ (รายการ <คุณสมบัติ>) คุณสมบัติ - หน่วยงานอิสระที่มีชื่อหน่วยการวัดประเภทข้อมูล ตัวอย่างเช่น "ชื่อ", "น้ำหนัก", "ขนาดหน้าจอ" คุณสมบัติเดียวกันสามารถมีผลิตภัณฑ์ที่แตกต่างกัน ผลิตภัณฑ์ - มีชื่อและรายการค่าที่เกี่ยวข้องกับคุณสมบัติ ค่าเป็นวัตถุที่มีเพียงฟิลด์ค่าและรหัสฟิลด์ของทรัพย์สิน ตอนแรกฉันตัดสินใจที่จะทำให้หมวดหมู่เป็นแบบรวมเดี่ยวในรูปแบบนี้เพราะตัวอย่างเช่นเมื่อฉันเพิ่มผลิตภัณฑ์ใหม่ฉันจำเป็นต้องทราบข้อมูลทั้งหมดที่เกี่ยวข้องกับหมวดหมู่ปัจจุบันรวมถึงคุณสมบัติที่เกี่ยวข้องกับหมวดหมู่ปัจจุบัน ( หมวดหมู่AddNewProduct (ผลิตภัณฑ์) ) แต่ฉันควรทำอย่างไรเมื่อฉันต้องเพิ่มคุณสมบัติใหม่ที่ไม่ได้อยู่ในหมวดหมู่ใด ๆ ตัวอย่างเช่นฉันไม่สามารถทำหมวดหมู่นี้ได้เพิ่มNewProperty (คุณสมบัติ)เพราะมันบอกอย่างชัดเจนว่าเราเพิ่มคุณสมบัติให้กับหมวดหมู่เฉพาะ ตกลงขั้นตอนถัดไปฉันตัดสินใจแยกคุณสมบัติเป็นการรวมแยกต่างหาก แต่จากนั้นจะเป็นรายการที่มีเอนทิตีง่าย แน่นอนฉันสามารถสร้างบางสิ่งบางอย่างเช่น PropertyAggregate เพื่อเก็บไว้ในรายการคุณสมบัติและกฎธุรกิจได้ แต่เมื่อฉันเพิ่มผลิตภัณฑ์ฉันต้องมีภายในหมวดหมู่รายการทั้งหมดของคุณสมบัติที่เป็นของหมวดนี้เพื่อตรวจสอบค่าคงที่ แต่ฉันก็ทราบด้วยว่าการเก็บลิงค์ภายในผลรวมของมวลรวมอื่นนั้นเป็นวิธีที่ไม่ดี ตัวเลือกในการออกแบบกรณีธุรกิจนี้มีอะไรบ้าง

10 domain-driven-design  entity  aggregate 

เราควรสร้างรูทรวมใหม่ในสถาปัตยกรรม cqrs อย่างไร ในตัวอย่างนี้ฉันต้องการสร้างรากรวม AR2 ใหม่ที่เก็บการอ้างอิงถึงหนึ่ง AR1 ฉันกำลังสร้าง AR2 โดยใช้วิธี AR1 เป็นจุดเริ่มต้น จนถึงตอนนี้ฉันเห็นตัวเลือกน้อย: Inside method ใน AR1 createAr2RootOpt1ฉันสามารถโทรnew AR2()และบันทึกออบเจ็กต์นี้ไปยัง db imediatelly โดยใช้บริการโดเมนที่มีที่เก็บข้อมูล ฉันสามารถปล่อยเหตุการณ์ในรากรวมแรกเช่น SholdCreateAR2Eventและจากนั้นก็มีเทพนิยายไร้สัญชาติที่ตอบสนองต่อสิ่งนี้และออกคำสั่งCreateAR2Commandที่ได้รับการจัดการและสร้าง AR2 และปล่อยออกAR2CreatedEventมา ในกรณีของการใช้การจัดหาเหตุการณ์SholdCreateAR2Eventจะไม่ถูกเก็บไว้ในที่จัดเก็บกิจกรรมเนื่องจากจะไม่ส่งผลกระทบต่อสถานะของการรวมรากแรก (หรือเราควรบันทึกสิ่งนี้ไว้ในที่จัดเก็บกิจกรรม) class AR1{ Integer id; DomainService ds; //OPTION 1 void createAr2RootOpt1(){ AR2 ar2 = new AR2(); ds.saveToRepo(ar2); } //OPTION 2 void createAr2RootOpt2(){ publishEvent(new …

10 domain-driven-design  event-programming  cqrs  event-sourcing  entity 

ฉันพยายามเรียนรู้วิธีการของ DDD และวิชาที่เกี่ยวข้อง ฉันมาพร้อมกับความคิดของบริบทที่ล้อมรอบง่าย ๆ ที่จะใช้ "ธนาคาร": มีบัญชีเงินสามารถฝากถอนและโอนระหว่างพวกเขา นอกจากนี้ยังเป็นสิ่งสำคัญในการเก็บประวัติการเปลี่ยนแปลง ฉันระบุเอนทิตี้ของบัญชีและการจัดหากิจกรรมนั้นเป็นเรื่องที่ดีในการติดตามการเปลี่ยนแปลง เอนทิตีหรือวัตถุค่าอื่น ๆ ไม่เกี่ยวข้องกับปัญหาดังนั้นฉันจะไม่พูดถึงพวกเขา เมื่อพิจารณาการฝากและถอน - มันค่อนข้างง่ายเพราะมีเพียงหนึ่งรวมที่แก้ไข เมื่อโอนเงินจะแตกต่างกัน - การรวมสองรายการจะต้องแก้ไขโดยเหตุการณ์MoneyTransferredหนึ่งเหตุการณ์ DDD เลิกใช้งานการแก้ไขการรวมหลายรายการในหนึ่งธุรกรรม ในอีกทางหนึ่งกฎของการจัดหากิจกรรมคือการใช้กิจกรรมกับหน่วยงานและแก้ไขสถานะตามพวกเขา หากสามารถเก็บเหตุการณ์ไว้ในฐานข้อมูลได้ก็จะไม่มีปัญหา แต่เพื่อป้องกันการปรับเปลี่ยนที่มาพร้อมกันของเอนทิตีที่มาของเหตุการณ์เราต้องใช้สิ่งที่กำหนดเวอร์ชันสตรีมเหตุการณ์ของแต่ละการรวม (เพื่อรักษาขอบเขตการทำธุรกรรม) ปัญหาอีกประการหนึ่งของการกำหนดเวอร์ชันคือฉันไม่สามารถใช้โครงสร้างแบบง่าย ๆ ในการจัดเก็บกิจกรรมและอ่านกลับเพื่อใช้กับการรวม คำถามของฉันคือ - ฉันจะนำหลักการทั้งสามเหล่านั้นมารวมกันได้อย่างไร: "หนึ่งรายการรวมหนึ่งธุรกรรม", "เหตุการณ์ -> การเปลี่ยนแปลงโดยรวม" และ "การป้องกันการแก้ไขพร้อมกัน"

10 domain-driven-design  event-sourcing 

ฉันได้ปรับการออกแบบที่ขับเคลื่อนด้วยโดเมนมาประมาณ 8 ปีแล้วและแม้กระทั่งหลังจากทุกปีเหล่านี้ก็ยังมีสิ่งหนึ่งที่ทำให้ฉันเบื่อ นั่นคือการตรวจสอบระเบียนที่ไม่ซ้ำกันในการจัดเก็บข้อมูลกับวัตถุโดเมน ในเดือนกันยายน 2013 Martin Fowler ได้กล่าวถึงหลักการ TellDonnaAskซึ่งหากเป็นไปได้ควรนำไปใช้กับวัตถุโดเมนทั้งหมดซึ่งควรจะส่งคืนข้อความว่าการดำเนินการเป็นไปอย่างไร (ในการออกแบบเชิงวัตถุ การดำเนินการไม่สำเร็จ) โครงการของฉันมักจะแบ่งออกเป็นหลายส่วนโดยที่สองในนั้นเป็นโดเมน (ที่มีกฎเกณฑ์ทางธุรกิจและไม่มีสิ่งอื่นใดโดเมนนั้นยังคงอยู่อย่างไม่รู้ตัว) และบริการ บริการที่ทราบเกี่ยวกับเลเยอร์พื้นที่เก็บข้อมูลที่ใช้กับข้อมูล CRUD เนื่องจากความเป็นเอกลักษณ์ของคุณสมบัติที่เป็นของวัตถุคือกฎของโดเมน / ธุรกิจจึงควรจะยาวไปยังโมดูลของโดเมนดังนั้นกฎจึงตรงตามที่ควรจะเป็น เพื่อให้สามารถตรวจสอบเอกลักษณ์ของระเบียนคุณต้องค้นหาชุดข้อมูลปัจจุบันซึ่งมักจะเป็นฐานข้อมูลเพื่อค้นหาไม่ว่าจะมีระเบียนอื่นที่มีการสมมติว่าNameมีอยู่แล้ว เมื่อพิจารณาว่าเลเยอร์ของโดเมนนั้นไม่รู้มานานแล้วและไม่รู้ว่าจะดึงข้อมูลได้อย่างไร แต่จะทำอย่างไรกับการดำเนินการกับมันพวกมันไม่สามารถสัมผัสที่เก็บข้อมูลได้ การออกแบบที่ฉันได้รับการปรับตัวแล้วมีลักษณะเช่นนี้: class ProductRepository { // throws Repository.RecordNotFoundException public Product GetBySKU(string sku); } class ProductCrudService { private ProductRepository pr; public ProductCrudService(ProductRepository repository) { pr = repository; } public …

10 object-oriented-design  domain-driven-design  service  unique-data 

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

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

ฉันมาจากโลกแห่งสคริปต์การทำธุรกรรมและฉันเพิ่งเริ่มดู DDD ฉันไม่แน่ใจในวิธีที่ถูกต้องในการรวมการออกแบบ DDD กับการคงอยู่ของฐานข้อมูล นี่คือสิ่งที่ฉันมี: คลาสเซอร์วิสชื่อ OrganisationService ซึ่งอินเตอร์เฟสมีเมธอดสำหรับการดึงและบันทึกอินสแตนซ์ของอ็อบเจ็กต์โดเมนองค์กร องค์กรเป็นรูทรวมและมีข้อมูลอื่น ๆ ที่เกี่ยวข้อง: สมาชิกและใบอนุญาต ฐานข้อมูล EF6 ก่อน DBContext จะใช้ภายใน OrganisationService เพื่อดึงหน่วยงาน OrganisationDB และหน่วยงาน MemberDB และ LicenseDB ที่เกี่ยวข้อง สิ่งเหล่านี้ทั้งหมดได้รับการแปรสภาพเป็นคลาสอ็อบเจ็กต์โดเมนเทียบเท่าเมื่อดึงข้อมูลโดย OrganisationService และโหลดลงในวัตถุโดเมนองค์กร วัตถุนี้ดูเหมือนว่า: public class Organisation { public IList<Member> Members { get; set; } public IList<License> Licenses { get; set; } } ฉันไม่ได้ใช้รูปแบบพื้นที่เก็บข้อมูลใน …

10 domain-driven-design 

ตามหลักการแบ่งแยกคำสั่งรวมถึงการคิดในข้อมูลและDDD ด้วยการนำเสนอClojureหนึ่งควรแยกผลข้างเคียง (แก้ไขโลก) จากการคำนวณและการตัดสินใจเพื่อให้ง่ายต่อการเข้าใจและทดสอบทั้งสองส่วน นี่เป็นคำถามที่ยังไม่ได้ตอบ: เราควรใส่ "ถามโลก" ที่ไหน ในอีกด้านหนึ่งการร้องขอข้อมูลจากระบบภายนอก (เช่นฐานข้อมูล, บริการนอกระบบ 'APIs และอื่น ๆ ) นั้นไม่ได้อ้างอิงอย่างโปร่งใสดังนั้นจึงไม่ควรใช้ร่วมกับการคำนวณและการตัดสินใจที่บริสุทธิ์ ในทางกลับกันมันเป็นปัญหาหรืออาจเป็นไปไม่ได้ที่จะหยอกล้อพวกเขานอกเหนือจากส่วนการคำนวณและส่งผ่านเป็นอาร์กิวเมนต์เนื่องจากเราอาจไม่ทราบล่วงหน้าว่าต้องการข้อมูลใด

10 functional-programming  domain-driven-design  clojure  design  side-effect 

ฉันกำลังทำงานกับระบบที่อนุญาตให้ผู้ดูแลระบบกำหนดฟอร์มที่มีฟิลด์ แบบฟอร์มที่กำหนดจะถูกใช้เพื่อป้อนข้อมูลไปยังระบบ บางครั้งแบบฟอร์มจะถูกกรอกโดยมนุษย์ผ่าน GUI บางครั้งแบบฟอร์มจะถูกกรอกตามค่าที่รายงานโดยระบบอื่น สำหรับแต่ละฟิลด์ผู้ดูแลระบบสามารถกำหนดกฎการตรวจสอบที่ จำกัด ค่าที่อนุญาตสำหรับฟิลด์ กฎการตรวจสอบสามารถเป็นอะไรก็ได้จาก "ค่าที่ป้อนในฟิลด์ต้องเป็นจริงหรือเท็จ" ถึง "ค่าที่ป้อนในฟิลด์ต้องมีอยู่ในคอลัมน์ A ของตาราง B ในฐานข้อมูล" ผู้ดูแลระบบสามารถเปลี่ยนแปลงกฎการตรวจสอบสำหรับฟิลด์ได้ตลอดเวลา ในสถานการณ์นี้ความคิดเห็นของคุณเป็นสถานที่ที่เหมาะสมที่สุดสำหรับการตรวจสอบว่าแต่ละเขตข้อมูลถูกกรอกอย่างถูกต้องหรือไม่ ฉันมีสองวิธีหลักในใจ: ตัวเลือก # 1: ตรวจสอบความถูกต้องในรูปแบบโดเมน แต่ละวัตถุฟิลด์จะมีกฎการตรวจสอบที่ระบุโดยผู้ดูแลระบบ วัตถุฟิลด์จะมีการอ้างอิงถึง IValidator เมื่อมีความพยายามในการตั้งค่าของฟิลด์ฟิลด์จะผ่านค่าที่กำหนดและกฎการตรวจสอบไปยัง IValidator หากค่าที่ระบุไม่ถูกต้องจะมีการโยน ValidationException และจัดการอย่างเหมาะสมใน GUI / อินเตอร์เฟสไปยังระบบอื่น ข้อดี: การป้องกันที่แข็งแกร่งสำหรับฟิลด์ที่ถูกกำหนดค่าโดยไม่ตั้งใจซึ่งละเมิดกฎการตรวจสอบ จุดด้อย: Data Access Layer ต้องสามารถผ่านการตรวจสอบและสร้างเขตข้อมูลที่ละเมิดกฎการตรวจสอบปัจจุบัน แม้ผู้ดูแลระบบจะเปลี่ยนกฎการตรวจสอบสำหรับเขตข้อมูล แต่เรายังจำเป็นต้องสร้างวัตถุเขตข้อมูลตามข้อมูลเก่าเช่นเมื่อแสดงแบบฟอร์มที่กรอกข้อมูลเมื่อหลายปีก่อน สิ่งนี้อาจแก้ไขได้โดยการเก็บกฎการตรวจสอบปัจจุบันเมื่อใดก็ตามที่เราเก็บฟิลด์ ในการออกแบบนี้โมเดลฟิลด์มีลิงก์ทางอ้อมไปยัง Data Access Layer / Repository …

10 design-patterns  architecture  domain-driven-design  validation 

ฉันเคยใช้เครื่องมือ MDA (สถาปัตยกรรมที่ขับเคลื่อนด้วยโมเดล) ในอดีตที่เราทำโมเดลผ่าน UML และสิ่งนี้ได้สร้างเอนทิตีธุรกิจ (โมเดลโดเมนของเรา) และ ORM (การทำแผนที่ ฯลฯ ) ท่ามกลางสิ่งอื่น ๆ รหัสธุรกิจและบริการจำนวนมากที่ทำงานบนโดเมนนั้นเป็นส่วนหนึ่งของแบบจำลองและที่เก็บของเราส่งคืนเอนทิตีธุรกิจ (ดังนั้นจึงเป็นไปไม่ได้ที่จะเปลี่ยนไปใช้ ORM อื่น (ไม่ใช่ที่เราต้องการ)) อย่างไรก็ตามตอนนี้ฉันกำลังเริ่มโครงการและฉันต้องการคิดในแง่ของ DDD จนถึงตอนนี้ฉันรู้สึกราวกับว่าฉันวางตรรกะทางธุรกิจของฉันในรูปแบบโดเมนของฉันและผ่านที่เก็บฉันจะทำงานร่วมกับ ORM (ซึ่งฉันเคยเลือก) อย่างไรก็ตามถ้าฉันต้องการใช้เครื่องมือ MDA สำหรับส่วน ORM ของแอปพลิเคชันต่อไปโมเดลที่สร้างขึ้นที่นี่จะเป็นโลหิตจางมาก (เช่นไม่มีตรรกะทางธุรกิจ) ในทำนองเดียวกันถ้าฉันใช้ Entity framework (.net) หรือ NHibernate สำหรับ ORM ของฉันมันก็จะเป็นแบบจำลองโลหิตจางด้วย? ฉันไม่แน่ใจว่าคุณจะใช้ตรรกะทางธุรกิจที่ใดถ้าฉันใช้ NHibernate ฉันถูกต้องในการคิดแบบนี้ในคำอื่น ๆ ที่มี DDD ตรรกะทางธุรกิจทั้งหมดในโดเมนและเพียงแค่ใช้ ORM สำหรับการคงอยู่ผ่านทางที่เก็บ?

10 orm  entity-framework  domain-model  nhibernate  domain-driven-design 

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

10 design-patterns  architecture  object-oriented  scrum  domain-driven-design 

ฉันเป็นมือใหม่ DDD ญาติ แต่ฉันกำลังอ่านอะไรและทุกอย่างที่ฉันสามารถรับในมือที่จะต้มออกและกลั่นความรู้ของฉัน ฉันเจอคำถาม DDD นี้และหนึ่งในคำตอบที่ฉันสนใจ บริบทและโดเมนที่ถูก จำกัด DDD? หนึ่งในคำตอบที่ผู้โพสต์ให้ตัวอย่างของระบบอีคอมเมิร์ซกับผลิตภัณฑ์ที่อยู่ในโดเมนอย่างน้อย 2 โดเมน: 1) แคตตาล็อกสินค้า 2) การจัดการสินค้าคงคลัง ตกลงนั่นคือเหตุผลทั้งหมดเช่นในส่วนหน้าอีคอมเมิร์ซของคุณคุณมีความสนใจในการแสดงข้อมูลผลิตภัณฑ์และไม่สนใจในการจัดการสินค้าคงคลัง แต่. คุณอาจต้องการแสดงระดับสินค้าคงคลังบนหน้าเว็บหรือคุณอาจต้องการแสดงหมายเลขรุ่นของสินค้าคงคลังในสต็อก (ลองนึกภาพว่าสินค้าคงคลังของคุณคือหนังสือนิตยสาร ฯลฯ ) ข้อมูลนี้มาจากโดเมนสินค้าคงคลัง ดังนั้นคุณจะจัดการกับสิ่งนี้อย่างไร คุณจะ a) โหลดทั้งโดเมนผลิตภัณฑ์และการรวมโดเมนสินค้าคงคลังหรือไม่ b) คุณจะถือคุณสมบัติบางอย่างในเอนทิตีโดเมนผลิตภัณฑ์ของคุณสำหรับตัวเลขในสต็อกและรุ่นในสต็อกจากนั้นใช้กิจกรรมโดเมนเพื่ออัปเดตเหล่านี้เมื่อมีการอัปเดตเอนทิตีสินค้าคงคลังหรือไม่ คำถามสุดท้ายหนึ่งข้อ ฉันรู้ว่าเราหมายถึงการลืม / เพิกเฉยต่อการคงอยู่ของโดเมนและเพียงแค่คิดถึงโดเมน แต่เพียงคิดผ่านตัวอย่างข้างต้นเราจะจบลงด้วย 2 DB ตารางที่อาจเกิดขึ้นสำหรับแคตตาล็อกสินค้าและสินค้าคงคลังสินค้า ตอนนี้เราจะใช้ตัวระบุเดียวกันในสิ่งเหล่านี้เพราะเป็นผลิตภัณฑ์เดียวกันหรือไม่ หรือเราสามารถใช้ 1 ตารางและ 1 แถวของตารางสำหรับข้อมูลและแมปข้อมูลที่เกี่ยวข้องกับคุณสมบัติรวมได้หรือไม่

10 domain-driven-design  domain-model 

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

10 domain-driven-design