ตารางการค้นหา: พวกมันรั่วในโมเดลโดเมนหรือไม่

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

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

• บริษัท
  • มีผู้ติดต่อ
• ติดต่อ
  • มีประเภทการติดต่อ
• ContactType (enum)
• CompanyRepository (อินเตอร์เฟส)
• EFCompanyRepository (กำหนดไว้ในแอสเซมบลีภายนอกใช้ EntityFramework ดำเนินการ CompanyRepository)

ทีมของเรามีความเห็นแยกกันเกี่ยวกับวิธีการสร้างแบบจำลองฐานข้อมูลสำหรับแอปพลิเคชันนี้

ด้าน A: DDDers แบบ Lean:

• เป็นหน้าที่ของโดเมนในการกำหนดว่า ContactTypes ใดที่ถูกต้องสำหรับที่ติดต่อ การเพิ่มตารางไปยังฐานข้อมูลเพื่อตรวจสอบว่า ContactTypes ที่ไม่รู้จักไม่ได้ถูกบันทึกเป็นสัญลักษณ์ของโดเมนที่รั่ว มันกระจายตรรกะออกไปไกลเกินไป
• การเพิ่มตารางคงที่ในฐานข้อมูลและรหัสที่เกี่ยวข้องนั้นสิ้นเปลือง ในแอปพลิเคชั่นนี้ฐานข้อมูลแก้ปัญหาหนึ่ง: ยืนยันสิ่งนั้นและส่งคืนให้ฉัน การเขียนตารางพิเศษและรหัส CRUD ที่เกี่ยวข้องนั้นสิ้นเปลือง
• การเปลี่ยนกลยุทธ์เพื่อการคงอยู่นั้นง่ายที่สุดเท่าที่จะทำได้ มีแนวโน้มที่จะเปลี่ยนกฎธุรกิจ ถ้าฉันตัดสินใจว่า SQL Server มีค่าใช้จ่ายมากเกินไปฉันไม่ต้องการสร้างการตรวจสอบความถูกต้องทั้งหมดที่ฉันใส่ไว้ในสคีมาใหม่อีกครั้ง

ด้าน B: นักอนุรักษนิยม [นั่นอาจไม่ใช่ชื่อที่ยุติธรรม DBCentrists?]:

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

ด้านใดถูกหรือผิด แต่อย่างใดอย่างหนึ่งอาจมีประสิทธิภาพมากขึ้นในระยะยาวการนับเวลาการพัฒนาสำหรับการพัฒนาเริ่มต้นข้อบกพร่อง ฯลฯ ด้านใด - หรือมีการประนีประนอมที่ดีกว่า? ทีมอื่น ๆ ที่เขียนโค้ดลักษณะนี้ทำอะไร

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

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

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

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

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

คำค้นหา: CQRS

ฉันพบว่าดีที่สุดในการจัดเก็บ enums เป็นตัวแทนสตริงในฐานข้อมูลและไม่รวมตารางการค้นหา

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

ด้านบวกคือฟิลด์ยังคงรักษาความหมายของมันไว้ในฐานข้อมูลคุณไม่ต้องลงเอยด้วยตัวเลขมายากลที่กัดกร่อนไปที่ค่า int ของ enum ตัวอย่างเช่นคุณไม่จำเป็นต้องจัดการเวอร์ชันการค้นหาเมื่อ enum เปลี่ยนแปลง

ไม่แน่ใจว่าฉันจะอธิบายลักษณะนี้ว่าเป็นความแตกต่าง DDD กับตราดอย่างไร ยิ่งไปกว่านั้นรหัสกับฐานข้อมูลส่วนกลางนั้นดีที่สุดในมุมมองของฉัน

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