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

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

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

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

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

ฉันกำลังดิ้นรนเพื่อค้นหาตัวอย่าง / ตัวอย่างที่ดีสำหรับสิ่งอื่นใดนอกเหนือจากกรณีพื้นฐานที่สุดของการใช้งาน

ปรับปรุง:

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

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

ดังนั้นฉันเดาว่าฉันถามจริง ๆ (และล้มเหลวในการระบุอย่างชัดเจน) เกี่ยวกับวิธีการที่สะอาดและส่วนที่เหลือ api จะนั่งกันที่สิ่ง MVC ส่วนใหญ่ที่คุณเห็นวันนี้มีการตรวจสอบคำขอเข้ามา (เช่นห้องสมุด FluentValidation ใน. NET) กฎ "การตรวจสอบความถูกต้อง" ของฉันไม่มาก "นี่คือสตริงที่มีอักขระน้อยกว่า 50 ตัว" แต่มากกว่านั้น "ผู้ใช้นี้สามารถโทรหาผู้ใช้ / ผู้โต้ตอบนี้ทำการดำเนินการนี้ในการเก็บข้อมูลนี้หรือไม่ จนกระทั่งภายหลังในเดือน ฯลฯ ฯลฯ "... การตรวจสอบที่เกี่ยวข้องอย่างลึกล้ำที่มีวัตถุทางธุรกิจและกฎโดเมนจำนวนมาก

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

สำหรับการอ้างอิงฉันกำลังออกบทความหลาย ๆ อย่างเช่นนี้แต่ Mattia ไม่ได้พูดถึงการตรวจสอบความถูกต้องมากนัก

แต่ฉันเดาว่าคำตอบสั้น ๆ สำหรับคำถามของฉันนั้นเหมือนกับคำตอบที่ฉันยอมรับ: "มันไม่ง่ายเลยและขึ้นอยู่กับมัน"

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

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

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

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

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

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

• เลเยอร์ธุรกิจควรทำการตรวจสอบรูปแบบส่วนใหญ่เพราะเฮ้พวกเขาอยู่ในชั้นธุรกิจในทางทฤษฎี

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

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

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

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

ฉันเห็นนักพัฒนาบางคนพยายามประมวลกฎการตรวจสอบความถูกต้องทั้งหมดในชั้นธุรกิจแล้วให้ชั้นอื่นเรียกว่าแยกกฎธุรกิจและสร้างการตรวจสอบความถูกต้องที่ชั้นอื่น ในทางทฤษฎีสิ่งนี้จะยอดเยี่ยมเพราะคุณต้องจบลงด้วยแหล่งความจริงเพียงแหล่งเดียว แต่ฉันไม่เคยเห็นวิธีการนี้ทำสิ่งอื่นใดนอกเหนือจากการแก้ปัญหาที่ไม่มีความซับซ้อนและมักจะจบลงอย่างเลวร้าย

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

การตรวจสอบเป็นส่วนหนึ่งของชั้นธุรกิจ

ประเด็นคือ: ตรรกะทางธุรกิจใน DAOs จะทำให้แนวคิด DAO เป็นโมฆะ หากต้องการตรวจสอบความถูกต้องในเลเยอร์ที่สูงกว่าจะส่งผลให้เกิดการตรวจสอบซ้ำซ้อนหากคุณเรียกการดำเนินธุรกิจจาก usecase อื่น

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

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

สิ่งนี้ใช้กับเลเยอร์ทั้งหมด ความสม่ำเสมอของการตรวจสอบเป็นกุญแจสำคัญ ทำให้การตรวจสอบของคุณมากที่สุดในโดเมนมากที่สุด ส่งคืนข้อ จำกัด ด้วย API ของคุณ ฉันสิ้นสุดไม่ได้นึกถึงข้อ จำกัด ที่มาจาก X library หรือ Z storage แต่จากการให้บริการ

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