คำถามติดแท็ก aggregate

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

40 performance  domain-driven-design  aggregate 

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

10 domain-driven-design  entity  aggregate