แนวทางปฏิบัติที่ดีที่สุดสำหรับการรวมเป็นอนุกรมของการรวม DDD

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

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

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

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

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

ชนิดของวัตถุ

สำหรับจุดประสงค์ของการสนทนาเราแยกวัตถุของเราออกเป็นสามประเภท:

ตรรกะโดเมนธุรกิจ

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

ตามปกติแล้ววัตถุลอจิกของโดเมนไม่จำเป็นต้องมี accessors (getters and setters) แต่คุณสร้างวัตถุโดยส่งมันขึ้นต่อกันผ่านคอนสตรัคแล้วจัดการกับวัตถุผ่านเมธอด (บอกอย่าถาม)

การถ่ายโอนข้อมูลวัตถุ

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

ดูวัตถุโมเดล

มุมมองวัตถุแบบจำลองประกอบด้วยการแสดงข้อมูลที่แสดง / แก้ไขได้ อาจมีตรรกะทางธุรกิจซึ่งปกติจะ จำกัด อยู่ที่การตรวจสอบความถูกต้องของข้อมูล ตัวอย่างของวัตถุรูปแบบการดูอาจเป็น InvoiceViewModel ซึ่งมีวัตถุลูกค้าวัตถุส่วนหัวของใบแจ้งหนี้และรายการโฆษณาใบแจ้งหนี้ ดูวัตถุรูปแบบมักจะมีการเข้าถึง

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

การทำให้เป็นลำดับการอ้างอิงและการมีเพศสัมพันธ์

ในขณะที่มันเป็นความจริงที่ทำให้เป็นอันดับสร้างการพึ่งพาในแง่ที่ว่าคุณต้อง deserialize เป็นวัตถุที่เข้ากันได้มันไม่จำเป็นต้องทำตามที่คุณต้องเปลี่ยนการกำหนดค่าของคุณเป็นอนุกรม กลไกการจัดลำดับที่ดีมีวัตถุประสงค์ทั่วไป พวกเขาไม่สนใจว่าคุณจะเปลี่ยนชื่อของทรัพย์สินหรือสมาชิกตราบใดที่มันยังสามารถแมปค่ากับสมาชิก ในทางปฏิบัติสิ่งนี้หมายความว่าคุณต้องทำให้เป็นอินสแตนซ์ของวัตถุอีกครั้งเพื่อทำให้การเป็นตัวแทน (xml, json หรืออะไรก็ตาม) เข้ากันได้กับวัตถุใหม่ของคุณ; ไม่จำเป็นต้องทำการเปลี่ยนแปลงการกำหนดค่าของซีเรียลไลเซอร์

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

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

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

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

มี 2 ​​เหตุผลที่ทำไมการใช้หนึ่งในรูปแบบเหล่านี้อาจไม่เหมาะ

1. อย่างมีประสิทธิภาพ

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

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

2. ความแม่นยำ

   การส่งข้อมูลที่จำเป็นในการซีเรียลไลซ์ / ดีซีเรียลไลซ์ของข้อมูลจากประเภทที่ต้องการไปยังประเภทข้อมูลที่ไม่เชื่อเรื่องพระเจ้าทำให้สูญเสียความแม่นยำ

เราอาจโต้แย้งได้ว่าการสร้างการแทนค่าวัตถุและข้อมูลเป็นวิธีแก้ปัญหาที่มีประสิทธิภาพและแม่นยำที่สุด ข้อเสียเปรียบที่สำคัญคือการใช้งานระบบทั้งหมดที่ใช้และผลิตข้อมูลจะต้องเข้ากันได้ มันเป็นข้อ จำกัด ทางทฤษฎีอย่างง่าย ๆ แต่เป็นฝันร้ายที่ต้องรักษาไว้ในทางปฏิบัติเนื่องจากระบบการผลิตมีแนวโน้มที่จะเปลี่ยนแปลง / เปลี่ยนแปลงตลอดเวลา

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