เริ่มต้นด้วยรูปแบบ DDD ในชั้นธุรกิจ

ฉันขอแนะนำให้คุณอ่านหนังสือของ Eric Evans เกี่ยวกับ Domain Driven Design (อีกครั้ง) ควรดูนายด้วย วิดีโอของอีแวนส์หลังหนังสือ DDD ไม่เกี่ยวกับพื้นที่เก็บข้อมูล ฐานข้อมูล แอสเซมบลี หรือการเข้าสู่ระบบของผู้ใช้

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

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

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

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