DDD Aggregates เป็นความคิดที่ดีจริงๆใน Web Application หรือไม่?

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

ยกตัวอย่างเช่นแนวคิดของ Aggregates คุณสร้างโดเมนเล็ก ๆ ของการเป็นเจ้าของเพื่อให้คุณไม่ต้องจัดการกับรูปแบบโดเมนทั้งหมด

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

ถ้าผมทำความเข้าใจขันธ์ขวาฉันมักจะใช้รูปแบบการเก็บข้อมูลที่จะกลับ OrderAggregate ว่าจะมีสมาชิกGetAll, GetByID, และDelete Saveตกลงนั่นฟังดูดี แต่...

ถ้าฉันโทร GetAll เพื่อแสดงรายการคำสั่งซื้อทั้งหมดของฉันดูเหมือนว่ารูปแบบนี้จะต้องมีการส่งคืนรายการข้อมูลรวมทั้งหมดคำสั่งซื้อที่สมบูรณ์คำสั่งซื้อบรรทัด ฯลฯ ... เมื่อฉันต้องการชุดย่อยของข้อมูลนั้นเพียงเล็กน้อย (เพียงแค่ข้อมูลส่วนหัว)

ฉันพลาดอะไรไปรึเปล่า? หรือมีการเพิ่มประสิทธิภาพในระดับหนึ่งที่คุณจะใช้ที่นี่ ฉันไม่สามารถจินตนาการได้ว่าใครก็ตามจะสนับสนุนให้ส่งคืนข้อมูลทั้งหมดเมื่อคุณไม่ต้องการ

แน่นอนหนึ่งสามารถสร้างวิธีการในพื้นที่เก็บข้อมูลของคุณชอบGetOrderHeadersแต่ที่ดูเหมือนจะเอาชนะวัตถุประสงค์ของการใช้รูปแบบเช่นพื้นที่เก็บข้อมูลในสถานที่แรก

ใครช่วยอธิบายเรื่องนี้ให้ฉันได้บ้าง

แก้ไข:

หลังจากการวิจัยมากขึ้นฉันคิดว่าการปลดการเชื่อมต่อที่นี่คือรูปแบบพื้นที่เก็บข้อมูลบริสุทธิ์แตกต่างจากสิ่งที่คนส่วนใหญ่คิดว่าเป็นพื้นที่เก็บข้อมูล

ฟาวเลอร์กำหนดที่เก็บเป็นที่เก็บข้อมูลที่ใช้ความหมายของการรวบรวมและโดยทั่วไปจะถูกเก็บไว้ในหน่วยความจำ นี่หมายถึงการสร้างกราฟวัตถุทั้งหมด

อีแวนส์เปลี่ยนแปลงที่เก็บเพื่อรวม Agotsate Roots และทำให้ที่เก็บถูกตัดเพื่อสนับสนุนวัตถุใน Aggregate เท่านั้น

คนส่วนใหญ่มักนึกถึงที่เก็บข้อมูลว่าเป็น Data Data Objects ที่ซึ่งคุณเพิ่งสร้างวิธีการรับข้อมูลที่คุณต้องการ ดูเหมือนจะไม่ได้มีเจตนาตามที่อธิบายไว้ในรูปแบบของสถาปัตยกรรมแอปพลิเคชัน Enterprise ของ Fowler

ยังมีคนอื่นคิดว่าที่เก็บเป็นนามธรรมที่เรียบง่ายใช้เป็นหลักในการทดสอบและการเยาะเย้ยง่ายขึ้นหรือเพื่อแยกความคงทนจากส่วนที่เหลือของระบบ

ฉันเดาคำตอบว่านี่เป็นแนวคิดที่ซับซ้อนกว่าที่ฉันคิดไว้ก่อน

อย่าใช้รูปแบบโดเมนของคุณและรวบรวมเพื่อการสืบค้น

ในความเป็นจริงสิ่งที่คุณถามเป็นคำถามที่พบได้บ่อยพอที่จะตั้งหลักการและรูปแบบขึ้นมาเพื่อหลีกเลี่ยงปัญหานั้น มันถูกเรียกว่าCQRS

ฉันดิ้นรนและยังคงดิ้นรนด้วยวิธีการใช้รูปแบบพื้นที่เก็บข้อมูลที่ดีที่สุดในการออกแบบการขับเคลื่อนด้วยโดเมน หลังจากใช้งานเป็นครั้งแรกฉันเริ่มทำตามวิธีปฏิบัติต่อไปนี้:

1. พื้นที่เก็บข้อมูลควรง่าย มันเป็นเพียงความรับผิดชอบในการจัดเก็บวัตถุโดเมนและดึงพวกเขา ตรรกะอื่น ๆ ทั้งหมดควรอยู่ในวัตถุอื่นเช่นโรงงานและบริการโดเมน

2. ที่เก็บทำงานเหมือนคอลเลกชันราวกับว่ามันเป็นคอลเลกชันในหน่วยความจำของรากรวม

3. ที่เก็บไม่ใช่ DAO ทั่วไปแต่ละที่เก็บมีอินเตอร์เฟสที่ไม่ซ้ำกันและแคบ ที่เก็บมักจะมีวิธีการค้นหาเฉพาะที่ช่วยให้คุณสามารถค้นหาคอลเลกชันในแง่ของโดเมน (ตัวอย่าง: ให้คำสั่งเปิดทั้งหมดสำหรับผู้ใช้ X) พื้นที่เก็บข้อมูลสามารถดำเนินการได้ด้วยความช่วยเหลือของ DAO ทั่วไป

4. ในอุดมคติแล้ววิธีการค้นหาจะกลับเฉพาะรากรวม หากไม่มีประสิทธิภาพมันยังสามารถส่งคืนวัตถุค่าที่อ่านได้อย่างเดียวซึ่งมีสิ่งที่คุณต้องการ (แม้ว่าจะเป็นข้อดีถ้าวัตถุค่าเหล่านี้สามารถแสดงในรูปของโดเมนได้) เป็นทางเลือกสุดท้ายที่เก็บสามารถใช้เพื่อส่งคืนชุดย่อยหรือชุดย่อยของชุดรวมของรูตรวม

5. ตัวเลือกเหล่านี้ขึ้นอยู่กับเทคโนโลยีที่ใช้เนื่องจากคุณต้องหาวิธีในการแสดงแบบจำลองโดเมนของคุณอย่างมีประสิทธิภาพด้วยเทคโนโลยีที่ใช้

ฉันไม่คิดว่าเมธอด GetOrderHeaders ของคุณจะทำลายจุดประสงค์ของพื้นที่เก็บข้อมูลเลย

DDD เกี่ยวข้อง (เหนือสิ่งอื่นใด) ด้วยการทำให้แน่ใจว่าคุณได้รับสิ่งที่คุณต้องการโดยวิธีการรวมรูท (คุณจะไม่มี OrderDetailsRepository เป็นต้น) แต่มันไม่ได้ จำกัด คุณในเรื่องที่คุณพูดถึง

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

การใช้ DDD ของฉันอาจไม่ถือว่า DDD "บริสุทธิ์" แต่ฉันได้ปรับกลยุทธ์ในโลกแห่งความจริงต่อไปนี้โดยใช้ DDD กับแหล่งข้อมูล DB

• รูทรวมมีที่เก็บข้อมูลที่เกี่ยวข้อง
• ที่เก็บที่เชื่อมโยงจะถูกใช้โดยรูทรวมเท่านั้น (ซึ่งจะไม่เปิดเผยต่อสาธารณะ)
• ที่เก็บสามารถมีการเรียกแบบสอบถาม (เช่น GetAllActiveOrders, GetOrderItemsForOrder)
• บริการเปิดเผยชุดย่อยสาธารณะของที่เก็บและการดำเนินการที่ไม่ crud อื่น ๆ (เช่นโอนเงินจากบัญชีธนาคารหนึ่งไปยังอีกบัญชีหนึ่ง LoadById, ค้นหา / ค้นหา, CreateEntity ฯลฯ )
• ฉันใช้รูท -> บริการ -> สแต็กที่เก็บ บริการ DDD นั้นควรจะใช้สำหรับสิ่งใดก็ตามที่ Entity ไม่สามารถตอบตัวเองได้ (เช่น LoadById, TransferMoneyFromAccountToAccount) แต่ในโลกแห่งความเป็นจริงฉันมักจะติดอยู่กับบริการ CRUD อื่น ๆ ที่เกี่ยวข้อง (บันทึกลบแบบสอบถาม) รูทควรจะสามารถ "ตอบ / ดำเนินการ" ด้วยตนเองได้ โปรดทราบว่าไม่มีอะไรผิดปกติกับการให้เอนทิตีเข้าถึงบริการรูทรวมอื่น! อย่างไรก็ตามโปรดจำไว้ว่าคุณจะไม่รวมอยู่ในบริการ (GetOrderItemsForOrder) แต่จะรวมไว้ในที่เก็บเพื่อให้ Aggregate Root สามารถใช้ประโยชน์ได้ โปรดทราบว่าบริการไม่ควรเปิดเผยข้อความค้นหาที่เปิดเช่นที่เก็บข้อมูล
• ฉันมักจะกำหนดพื้นที่เก็บข้อมูลที่เป็นนามธรรมในรูปแบบโดเมน (ผ่านอินเตอร์เฟซ) และให้การใช้งานที่แยกต่างหาก ฉันกำหนดบริการอย่างเต็มที่ในโดเมนแบบฉีดในพื้นที่เก็บข้อมูลคอนกรีตสำหรับการใช้งาน

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

ในตัวอย่างของคุณฉันอาจให้การเรียกใช้ที่เก็บซึ่งนำเฉพาะส่วนหัวของคำสั่งถ้าฉันต้องการโหลดรายละเอียดในการโทรแยกต่างหาก โปรดทราบว่าด้วยการมี "OrderHeader" เราจะแนะนำแนวคิดเพิ่มเติมในโดเมน

แบบจำลองโดเมนของคุณมีตรรกะทางธุรกิจในรูปแบบที่บริสุทธิ์ที่สุด ความสัมพันธ์และการดำเนินงานทั้งหมดที่สนับสนุนการดำเนินธุรกิจ สิ่งที่คุณขาดหายไปจากแผนที่แนวคิดของคุณคือแนวคิดของApplication Service Layer ที่เลเยอร์บริการจะล้อมรอบโมเดลโดเมนและให้มุมมองที่เรียบง่ายของโดเมนธุรกิจ โดยไม่ส่งผลกระทบโดยตรงต่อแอปพลิเคชันโดยใช้ชั้นบริการ

ก้าวต่อไป แนวคิดของการรวมคือมีวัตถุหนึ่งรูทรวมที่รับผิดชอบในการรักษาความมั่นคงของมวลรวม ในตัวอย่างของคุณคำสั่งซื้อจะต้องรับผิดชอบต่อการจัดการรายการสั่งซื้อ

สำหรับตัวอย่างของคุณเลเยอร์บริการจะแสดงการดำเนินการเช่น GetOrdersForCustomer ซึ่งจะส่งคืนสิ่งที่จำเป็นเพื่อดูรายการสรุปของคำสั่งซื้อเท่านั้น (เมื่อคุณเรียกพวกเขาว่า OrderHeaders)

สุดท้ายรูปแบบพื้นที่เก็บข้อมูลไม่ได้เป็นเพียงแค่คอลเลกชัน แต่ยังอนุญาตสำหรับการสืบค้นที่ประกาศ ใน C # คุณสามารถใช้ LINQ เป็นวัตถุ Queryหรือ O / RM อื่น ๆ ส่วนใหญ่จะให้ข้อมูลจำเพาะ Query Object ด้วยเช่นกัน

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

เมื่อเห็นว่าคุณสามารถสร้างคิวรีกับที่เก็บได้มันก็สมเหตุสมผลที่จะให้วิธีการอำนวยความสะดวกที่จัดการคิวรีทั่วไป เช่นถ้าคุณต้องการส่วนหัวของคำสั่งซื้อของคุณคุณสามารถสร้างแบบสอบถามที่ส่งกลับเฉพาะส่วนหัวและเปิดเผยจากวิธีการอำนวยความสะดวกในที่เก็บของคุณ

หวังว่านี่จะช่วยชี้แจงสิ่งต่าง ๆ

ฉันรู้ว่านี่เป็นคำถามเก่า แต่ดูเหมือนว่าฉันจะได้คำตอบที่ต่างออกไป

เมื่อฉันสร้างที่เก็บโดยทั่วไปแล้วจะมีการห่อแบบสอบถามที่แคชไว้

ฟาวเลอร์กำหนดที่เก็บเป็นที่เก็บข้อมูลที่ใช้ความหมายของการรวบรวมและโดยทั่วไปจะถูกเก็บไว้ในหน่วยความจำ นี่หมายถึงการสร้างกราฟวัตถุทั้งหมด

เก็บที่เก็บเหล่านั้นไว้ในเซิร์ฟเวอร์ของคุณ ram พวกมันไม่เพียงแค่ผ่านวัตถุไปยังฐานข้อมูล!

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

ณ จุดนี้คุณมีสองตัวเลือก

1. คุณสามารถสืบค้นฐานข้อมูลและดึงสิ่งที่คุณต้องการทำรายชื่อกลับมาแล้วค้นหาอีกครั้งเพื่อดึงรายละเอียดส่วนบุคคลที่คุณต้องการดูในหน้ารายละเอียด

2. คุณสามารถสร้าง 1 คิวรีที่ดึงข้อมูลทั้งหมดและแคชไว้ ในหน้าถัดไปขอให้คุณอ่านจากเซิร์ฟเวอร์ ram แทนฐานข้อมูล หากผู้ใช้กลับมาหรือเลือกหน้าถัดไปคุณยังคงไม่ต้องเดินทางไปที่ฐานข้อมูล

ในความเป็นจริงวิธีที่คุณใช้มันเป็นเพียงแค่นั้นและรายละเอียดการใช้งาน หากผู้ใช้ที่ใหญ่ที่สุดของฉันมี 10 คำสั่งซื้อฉันอาจต้องการไปกับตัวเลือก 2 ถ้าฉันกำลังพูดถึง 10,000 คำสั่งซื้อตัวเลือกที่ 1 เป็นสิ่งจำเป็น ในทั้งสองกรณีข้างต้นและในอีกหลายกรณีฉันต้องการที่เก็บเพื่อซ่อนรายละเอียดการใช้งานนั้น

ไปข้างหน้าถ้าฉันได้รับตั๋วเพื่อบอกผู้ใช้ว่าพวกเขาใช้จ่ายกับการสั่งซื้อ ( ข้อมูลรวม ) ในเดือนที่แล้วในหน้ารายการสั่งซื้อฉันจะเขียนตรรกะเพื่อคำนวณว่าใน SQL และเดินทางไปอีกรอบ ฐานข้อมูลหรือคุณต้องการคำนวณโดยใช้ข้อมูลที่มีอยู่ในเซิร์ฟเวอร์ ram หรือไม่

ในการรวมโดเมนประสบการณ์ของฉันมีประโยชน์มาก

• พวกมันคือการนำโค้ดขนาดใหญ่มาใช้ซ้ำได้ผลจริง
• พวกเขาลดความซับซ้อนของรหัสโดยทำให้ตรรกะทางธุรกิจของคุณอยู่ในชั้นหลักแทนที่จะต้องเจาะผ่านชั้นโครงสร้างพื้นฐานเพื่อรับเซิร์ฟเวอร์ sql ที่จะทำ
• พวกเขายังสามารถเร่งเวลาการตอบสนองของคุณได้อย่างมากโดยลดจำนวนการค้นหาที่คุณต้องการเนื่องจากคุณสามารถแคชได้อย่างง่ายดาย
• SQL ที่ฉันเขียนมักจะบำรุงรักษาได้ดีกว่าเพราะฉันมักจะถามทุกอย่างและคำนวณฝั่งเซิร์ฟเวอร์