คุณอาจต้องการแสดงระดับสินค้าคงคลังบนหน้าเว็บหรือคุณอาจต้องการแสดงหมายเลขรุ่นของสินค้าคงคลังในสต็อก (ลองนึกภาพว่าสินค้าคงคลังของคุณคือหนังสือนิตยสาร ฯลฯ ) ข้อมูลนี้มาจากโดเมนสินค้าคงคลัง
สิ่งสำคัญที่ควรสังเกต ณ จุดนี้คือคุณกำลังพูดถึงมุมมองซึ่งกล่าวได้ว่าการใช้ข้อมูลเก่านั้นเป็นที่ยอมรับ
ดังที่ได้กล่าวไปแล้วคุณไม่จำเป็นต้องโต้ตอบกับมวลรวม (ซึ่งมีหน้าที่ป้องกันการเปลี่ยนแปลงจากการละเมิดค่าคงที่ทางธุรกิจ) แต่ด้วยการเป็นตัวแทนของสำเนาล่าสุดของสถานะของมวลรวม
ดังนั้นสิ่งที่ฉันคาดหวังตามปกติคือการเรียกใช้แบบสอบถามกับแคตตาล็อกผลิตภัณฑ์และการเรียกใช้อีกรายการหนึ่งกับสินค้าคงคลังและสิ่งที่จะเขียนทั้งสองเป็น DTO ที่คุณต้องการสนับสนุนมุมมอง
โหลดทั้งโดเมนผลิตภัณฑ์และการรวมโดเมนสินค้าคงคลังหรือไม่
ดังนั้นที่ใกล้ เราไม่จำเป็นต้องโหลดมวลรวมเพราะเราจะไม่เปลี่ยนแปลงอะไรเลย แต่เราต้องการสถานะของพวกเขา ดังนั้นเราสามารถโหลดมันได้ ที่กล่าวว่าโดยปกติฉันคาดหวังว่าทั้งสองโดเมนจะทำงานในกระบวนการที่แตกต่างกัน ดังนั้นเราจะเรียกทั้งคู่ไม่ใช่โหลดทั้งคู่
คุณจะถือคุณสมบัติบางอย่างในเอนทิตีโดเมนผลิตภัณฑ์ของคุณสำหรับจำนวนในสต็อกและรุ่นในสต็อกแล้วใช้กิจกรรมโดเมนเพื่ออัปเดตเหล่านี้เมื่อมีการปรับปรุงเอนทิตีสินค้าคงคลัง?
"อย่าข้ามลำธารมันจะไม่ดี"
การใช้เหตุการณ์เพื่อประสานข้อมูลข้ามบริบทของโดเมน: แนวคิดที่ยอดเยี่ยม การพุชคอนเซ็ปต์ที่อยู่ในโดเมนหนึ่งไปยังอีกโดเมนหนึ่ง: ตรงข้ามกับแนวคิดที่ดียกเว้นอย่างนั้น
คุณต้องการให้โดเมนสะอาด การใช้งานที่ทำงานกับโดเมนก็ไม่ให้ความสำคัญ ตัวอย่างเช่นมีความเหมาะสมสำหรับแอปพลิเคชันสินค้าคงคลังที่จะเรียกใช้บริการในแอปพลิเคชันผลิตภัณฑ์เพื่อสอบถามแนวคิดเฉพาะผลิตภัณฑ์เพื่อเพิ่มไปยังมุมมอง หรือในทางกลับกัน
ฉันไม่ทราบด้วยเหตุผลใด ๆ ว่าแอปพลิเคชันเดียวจะต้องถูก จำกัด ในโดเมนเดียว ตราบใดที่มีแหล่งความจริงเพียงแหล่งเดียวคุณสามารถกระจายการทำธุรกรรมในแบบที่คุณชอบ
แต่เพียงคิดผ่านตัวอย่างข้างต้นเราจะจบลงด้วย 2 DB ตารางที่อาจเกิดขึ้นสำหรับแคตตาล็อกสินค้าและสินค้าคงคลังสินค้า ตอนนี้เราจะใช้ตัวระบุเดียวกันในสิ่งเหล่านี้เพราะเป็นผลิตภัณฑ์เดียวกันหรือไม่
นั่นจะเป็นวิธีที่ง่าย คุณใช้ตัวระบุเดียวกันเนื่องจากเอนทิตีโลกแห่งความจริงเหมือนกัน บริบทที่แตกต่างกันสองแบบที่เอนทิตี้ของแตกต่างกัน แต่โมเดลไม่ใช่เอนทิตีโลกแห่งความจริง
เมื่อไม่ได้ผลคุณจะต้องใช้แบบสอบถามเพื่อเชื่อมช่องว่าง ฉันคิดว่าการเปลี่ยนแปลงที่พบบ่อยที่สุดของสิ่งนี้คือเอนทิตีที่ใหม่กว่ารักษา ID ของเอนทิตีที่เก่ากว่า คุณจะเห็นสิ่งนี้ภายใน BC เดียวเช่นกัน: ผู้สมัครเมื่อได้รับการอนุมัติจะเป็นลูกค้า มันเป็นผลรวมที่แตกต่างกัน (สถานะที่เกี่ยวข้องกับไคลเอนต์ต้องมีค่าคงที่ที่แตกต่างจากของผู้สมัคร); ดังนั้นหากเลเยอร์การคงอยู่ของคุณกำลังใช้สตรีมเหตุการณ์สตรีมสำหรับการรวมใหม่จะต้องใช้ตัวระบุอื่น ดังนั้นจะมีรัฐสักหน่อยที่บอกว่า "ผู้สมัครรายนี้กลายเป็นลูกค้ารายนี้"
หรือเราสามารถใช้ 1 ตารางและ 1 แถวของตารางสำหรับข้อมูลและแมปข้อมูลที่เกี่ยวข้องกับคุณสมบัติรวมได้หรือไม่
YIKES! ไม่ทำอย่างนั้น คุณกำลังเพิ่มการช่วงชิงธุรกรรมโดยไม่มีเหตุผลทางธุรกิจในการทำเช่นนั้น