เหตุใดฉันจึงควรแยกเอนทิตีโดเมนของฉันออกจากเลเยอร์การนำเสนอของฉัน

ส่วนหนึ่งของการออกแบบที่ขับเคลื่อนด้วยโดเมนซึ่งดูเหมือนจะไม่มีรายละเอียดมากนักนั่นคือวิธีและเหตุผลที่คุณควรแยกโมเดลโดเมนของคุณออกจากอินเทอร์เฟซของคุณ ฉันพยายามโน้มน้าวเพื่อนร่วมงานว่านี่เป็นแนวทางปฏิบัติที่ดี แต่ดูเหมือนฉันจะไม่ค่อยก้าวหน้าสักเท่าไหร่ ...

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

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

1. เหตุใดเราจึงไม่ควรใช้วัตถุโดเมนในเลเยอร์การนำเสนอของเรา
   (หากคำตอบคือคำตอบที่ชัดเจน "การแยกส่วน" โปรดอธิบายว่าเหตุใดจึงมีความสำคัญในบริบทนี้)
2. เราควรใช้ออบเจ็กต์หรือโครงสร้างเพิ่มเติมเพื่อแยกออบเจ็กต์โดเมนของเราออกจากอินเทอร์เฟซหรือไม่?

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

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

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

แทนที่จะโหลด CompanyObject ซึ่งอาจมีการอ้างอิงถึงการสมัครสมาชิกหรือใครรู้อะไรอีกฉันสามารถส่ง DTO กลับพร้อมชื่อและรหัสได้ นี่เป็นการใช้ IMHO ที่ดี

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

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

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

เหตุใดคุณจึงใส่รหัสการสร้าง UI ในออบเจ็กต์ busienss ในกรณีของฉันฉันได้แยกวัตถุที่สร้างรหัส UI แยกจาก UI ฉันมีวัตถุที่ทำให้วัตถุทางธุรกิจของฉันกลายเป็น Xml ความคิดที่ว่าคุณต้องแยกเลเยอร์ของคุณเพื่อป้องกันการปนเปื้อนประเภทนี้เป็นเรื่องแปลกสำหรับฉันเพราะทำไมคุณถึงใส่รหัสการสร้าง HTML ในวัตถุทางธุรกิจ ...

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

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

คุณทำด้วยเหตุผลเดียวกับที่คุณไม่ให้ SQL ออกจากเพจ ASP / JSP ของคุณ

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

คุณต้องการใช้วิดเจ็ต UI ที่ดีในแอปอื่นหรือไม่? คุณต้องสร้างฐานข้อมูลด้วยชื่อนี้สคีมาทั้งสองนี้และ 18 ตารางเหล่านี้ คุณต้องกำหนดค่า Hibernate และ Spring (หรือกรอบงานที่คุณเลือก) เพื่อทำการตรวจสอบความถูกต้องทางธุรกิจ อ้อคุณต้องรวมคลาสอื่น ๆ ที่ไม่เกี่ยวข้องอีก 85 คลาสด้วยเพราะมันถูกอ้างอิงในชั้นธุรกิจซึ่งจะอยู่ในไฟล์เดียวกัน

ฉันไม่เห็นด้วย.

ฉันคิดว่าวิธีที่ดีที่สุดคือเริ่มต้นด้วยวัตถุโดเมนในเลเยอร์การนำเสนอของคุณจนกว่าจะมีความรู้สึกที่จะทำอย่างอื่น

ตรงกันข้ามกับความเชื่อที่นิยม "Domain Objects" และ "Value Objects" สามารถอยู่ร่วมกันได้อย่างมีความสุขในเลเยอร์การนำเสนอ และนี่เป็นวิธีที่ดีที่สุด - คุณจะได้รับประโยชน์จากทั้งสองโลกลดการซ้ำซ้อน (และรหัสสำเร็จรูป) ด้วยวัตถุโดเมน และการปรับแต่งและการปรับแนวคิดให้เรียบง่ายในการใช้ออบเจ็กต์มูลค่าข้ามคำขอ

คำตอบขึ้นอยู่กับขนาดของใบสมัครของคุณ

แอปพลิเคชั่น CRUD อย่างง่าย (สร้างอ่านอัปเดตลบ)

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

แอปพลิเคชั่น Non-CRUD ที่ซับซ้อนพอสมควร

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

การเพิ่ม DTO ในกรณีนี้เป็นความคิดที่ดีด้วยเหตุผลบางประการ:

• เลเยอร์การนำเสนอสามารถเห็นเฉพาะส่วนย่อยของฟิลด์ที่เอนทิตีมี คุณห่อหุ้มเอนทิตี
• ไม่มีการเชื่อมต่อระหว่างแบ็กเอนด์และส่วนหน้า
• หากคุณมีวิธีการทางธุรกิจภายในเอนทิตี แต่ไม่มีใน DTO การเพิ่ม DTO หมายความว่าโค้ดภายนอกไม่สามารถทำลายสถานะของเอนทิตีของคุณได้

แอปพลิเคชันองค์กรที่ซับซ้อน

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

เรากำลังใช้โมเดลเดียวกันในเซิร์ฟเวอร์และบน UI และมันเป็นความเจ็บปวด เราต้องรีแฟคเตอร์ใหม่สักวัน

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

ปัญหาอีกประการหนึ่งคือเอนทิตีบน UI ไม่เหมาะสมจริงๆ เรากำลังใช้ databinding และเอนทิตีจำนวนมากมีคุณสมบัติซ้ำซ้อนจำนวนมากสำหรับวัตถุประสงค์ ui เท่านั้น นอกจากนี้ยังมี 'BrowsableAttribute' และอื่น ๆ อีกมากมายในโมเดลเอนทิตี นี่มันแย่จริงๆ

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

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

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

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

อินเทอร์เฟซเป็นข้อมูลเกี่ยวกับอินพุตและมุมมองที่จัดเตรียมไว้สำหรับแกนการทำงานที่ถูกจำลองอย่างเหมาะสมและไม่แปรผัน

ฉันขอสาบานนี่คือความคงอยู่

อย่างไรก็ตามมันเป็นอีกหนึ่งกรณีที่เหมือนกัน: กฎของ Parnas กล่าวว่าโมดูลควรเก็บเป็นความลับและความลับเป็นข้อกำหนดที่สามารถเปลี่ยนแปลงได้ (บ๊อบมาร์ตินมีกฎที่รุ่นนี้อีก.) ในระบบเช่นนี้ที่นำเสนอสามารถเปลี่ยนเป็นอิสระจากโดเมน เช่น บริษัท ที่รักษาราคาในสกุลเงินยูโรและใช้ภาษาฝรั่งเศสในสำนักงานของ บริษัท แต่ต้องการแสดงราคาเป็นดอลลาร์พร้อมข้อความเป็นภาษาจีนกลาง โดเมนเป็นเดียวกัน; การนำเสนอสามารถเปลี่ยนแปลงได้ ดังนั้นเพื่อลดความเปราะบางของระบบให้เหลือน้อยที่สุดนั่นคือจำนวนสิ่งที่ต้องเปลี่ยนแปลงเพื่อใช้การเปลี่ยนแปลงข้อกำหนด - คุณแยกข้อกังวลออก

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

บางทีคุณอาจไม่ได้กำหนดคอนเซ็ปต์เลเยอร์ UI ให้กว้างพอ คิดในรูปแบบของการตอบสนองหลายรูปแบบ (หน้าเว็บการตอบกลับด้วยเสียงตัวอักษรที่พิมพ์ออกมา ฯลฯ ) และในหลายภาษา (อังกฤษฝรั่งเศส ฯลฯ )

สมมติว่าเอ็นจิ้นการพูดสำหรับระบบโทรเข้าทางโทรศัพท์ทำงานบนคอมพิวเตอร์ประเภทอื่นอย่างสิ้นเชิง (เช่น Mac) จากคอมพิวเตอร์ที่ใช้งานเว็บไซต์ (อาจเป็น Windows)

แน่นอนว่ามันง่ายมากที่จะตกหลุมพราง "ใน บริษัท ของฉันเราสนใจ แต่ภาษาอังกฤษเท่านั้นรันเว็บไซต์ของเราบน LAMP (Linux, Apache, MySQL และ PHP) และทุกคนก็ใช้ Firefox เวอร์ชันเดียวกัน" แต่ใน 5 หรือ 10 ปีล่ะ?

ดูส่วน "การเผยแพร่ข้อมูลระหว่างเลเยอร์" ในส่วนต่อไปนี้ซึ่งฉันคิดว่ามีข้อโต้แย้งที่น่าสนใจ:

http://galaxy.andromda.org/docs/andromda-documentation/andromda-getting-started-java/java/index.html

ด้วยความช่วยเหลือของเครื่องมือเช่น ' Value Injecter ' และแนวคิดของ 'Mappers' ในเลเยอร์การนำเสนอในขณะที่ทำงานกับมุมมองทำให้เข้าใจโค้ดแต่ละชิ้นได้ง่ายขึ้นมาก หากคุณมีโค้ดเล็กน้อยคุณจะไม่เห็นข้อดีในทันที แต่เมื่อโครงการของคุณเติบโตขึ้นเรื่อย ๆ คุณจะมีความสุขมากในขณะที่ทำงานกับมุมมองที่ไม่ต้องเข้าสู่ตรรกะของบริการ ที่เก็บเพื่อทำความเข้าใจโมเดลมุมมอง View Model เป็นอีกหนึ่งผู้พิทักษ์ในโลกแห่งการต่อต้านคอร์รัปชั่นที่กว้างใหญ่และคุ้มค่ากับทองคำในโครงการระยะยาว

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

นี่คือตัวอย่างที่แท้จริงว่าเหตุใดฉันจึงพบแนวทางปฏิบัติที่ดีในการแยกเอนทิตีโดเมนออกจากมุมมอง

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

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

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

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

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

การออกแบบที่ขับเคลื่อนด้วยโดเมนจะทำงานได้ดีที่สุดเมื่อใช้ร่วมกับชุดเฟรมเวิร์กโดเมนที่ใช้งานได้ในมุมฉาก (เช่น ORM, GUI, เวิร์กโฟลว์ ฯลฯ ) จำไว้เสมอว่ามันเป็นเพียงการปรับระดับชั้นนอกที่ความหมายของโดเมนจำเป็นต้องเปิดเผย โดยทั่วไปจะเป็นส่วนหน้า (GUI) และส่วนหลังแบบต่อเนื่อง (RDBM, ORM) เลเยอร์การแทรกแซงที่ออกแบบอย่างมีประสิทธิภาพใด ๆ สามารถและควรเป็นค่าคงที่ของโดเมน