ใน DDD ตรรกะการตรวจสอบแอปพลิเคชันหรือตรรกะโดเมนคืออะไร?

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

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

• เฟรมเวิร์กบางตัวเช่น Laravel จัดเตรียมกฎการตรวจสอบที่สามารถตรวจสอบอินพุตก่อนที่คำร้องขอจะเข้าควบคุม DDD แตกหรือไม่หากการตรวจสอบเสร็จในระดับนั้น

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

• จำเป็นหรือไม่ที่จะต้องตรวจสอบอินพุตทั้งที่แอ็พพลิเคชันและเลเยอร์โดเมน?

การตรวจสอบความถูกต้องเช่นนี้อยู่ในโดเมนหรือเลเยอร์แอปพลิเคชันหรือไม่

ใบสมัคร คำค้นหาเวทมนต์ที่คุณต้องการคือเลเยอร์ต่อต้านการทุจริต

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

ตัวอย่าง: คำสั่ง DepositMoney น่าจะมีจำนวนและประเภทสกุลเงิน การแทนค่า DTO อาจแสดงจำนวนเป็นจำนวนเต็มและรหัสสกุลเงินเป็นสตริง เลเยอร์ต่อต้านการคอร์รัปชั่นจะแปลง DTO เป็นประเภทมูลค่าเงินฝากซึ่งจะรวมถึงจำนวนเงินที่ผ่านการตรวจสอบแล้ว (ซึ่งต้องไม่ใช่ค่าลบ) และ CurrencyCode ที่ผ่านการตรวจสอบแล้ว (ซึ่งต้องเป็นหนึ่งในรหัสที่รองรับในโดเมน)

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

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

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

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

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

พิจารณาว่ามีกฎเกณฑ์ทางธุรกิจสองประเภท: - กฎคุณสมบัติที่ จำกัด คุณสมบัติของวัตถุและกฎการทำงานร่วมกันที่ จำกัด การเพิ่มและการลบการทำงานร่วมกันระหว่างวัตถุ

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

หมายเหตุ: ไม่มีแนวคิดใน DDD ของ "การสร้างแบบจำลอง" แบบฟอร์มของคุณ

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

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

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

เลเยอร์โดเมนควรมีตรรกะการตรวจสอบทั้งหมด การนำเสนอเลเยอร์ต่อต้านการทุจริตหรือเลเยอร์ขึ้นอยู่กับอื่น ๆ