ตัวจัดการคำสั่งและ DDD

ฉันมีแอพพลิเคชั่น ASP.NET MVC ที่ใช้บริการสอบถามเพื่อรับข้อมูลและบริการคำสั่งเพื่อส่งคำสั่ง คำถามของฉันเกี่ยวกับส่วนคำสั่ง

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

ตัวอย่างที่เป็นรูปธรรม: AddCommentToArticleCommandHandler ได้รับ AddCommentToArticleCommand ซึ่งมี ArticleId, CommentText และ EmailAddress

ครั้งแรก; การตรวจสอบจะต้องเกิดขึ้นเช่น: - ตรวจสอบว่ามีบทความอยู่หรือไม่ - ตรวจสอบว่าบทความไม่ได้ปิดอยู่หรือไม่ - ตรวจสอบว่ามีการกรอกข้อความแสดงความคิดเห็นและระหว่าง 20 ถึง 500 อักขระหรือไม่ - ตรวจสอบว่ากรอกอีเมลแล้วหรือไม่

ฉันสงสัยว่าจะใช้การตรวจสอบนี้ที่ไหน

1 / ในตัวจัดการคำสั่งเอง แต่จะไม่สามารถนำกลับมาใช้ใหม่ได้ในตัวจัดการคำสั่งอื่น

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

3 / ตัวจัดการคำสั่งใช้ตัวตรวจสอบความถูกต้องเพื่อให้การตรวจสอบสามารถนำกลับมาใช้ในตัวจัดการคำสั่งอื่น ๆ

4 / กลไกอื่น ๆ ?

ฉันกำลังมองหาความรับผิดชอบของตัวอย่างเฉพาะนี้และวัตถุใด (เอนทิตีที่เก็บ, ... ) มีบทบาทในมัน

คุณมีความคิดเกี่ยวกับวิธีการใช้งานนี้เริ่มต้นจากตัวจัดการคำสั่งจนถึงที่เก็บ?

ฉันคิดว่าคุณต้องแยกการตรวจสอบสองประเภทในกรณีนี้ ตรวจสอบโดเมนและการตรวจสอบการประยุกต์ใช้

การตรวจสอบความถูกต้องของแอปพลิเคชันคือสิ่งที่คุณมีเมื่อคุณตรวจสอบว่า 'ข้อความ' คุณสมบัติคำสั่งอยู่ระหว่าง 20 ถึง 200 อักขระ ดังนั้นคุณจึงตรวจสอบสิ่งนี้กับ GUI และกับ view-model-validator ที่ดำเนินการที่เซิร์ฟเวอร์หลัง POST เช่นเดียวกันสำหรับอีเมล (btw ฉันหวังว่าคุณจะเข้าใจว่าอีเมลเช่น `32.d +" Hello World .42 "@ mindomän.local" นั้นถูกต้องตาม RFC)

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

ในกรณีข้างต้นคุณจะมีโครงสร้างพื้นฐานที่จัดการข้อความพิษตัวอย่างเช่นลองอีกครั้งข้อความ 1-5 ครั้งจากนั้นย้ายไปยังคิว poision ที่คุณสามารถตรวจสอบการรวบรวมข้อความด้วยตนเองและส่งซ้ำที่เกี่ยวข้องเหล่านั้นอีกครั้ง มันเป็นสิ่งที่ดีในการตรวจสอบ

ดังนั้นตอนนี้เราได้กล่าวถึง:

• การตรวจสอบแอปพลิเคชัน

  • ด้วย javascript ใน GUI
  • ด้วยการตรวจสอบ MVC ที่เว็บเซิร์ฟเวอร์

• ไม่มีคิวรวม root + พิษที่ขาดหายไป

เกี่ยวกับคำสั่งที่ไม่ซิงค์กับโดเมน บางทีคุณอาจมีกฎในตรรกะโดเมนของคุณที่บอกว่าหลังจากความคิดเห็น 5 บทความบทความอนุญาตให้แสดงความคิดเห็นด้านล่างได้เพียง 400 ตัวอักษร แต่ผู้ชายคนหนึ่งสายเกินไปที่จะแสดงความคิดเห็นที่ 5 และต้องเป็นอันดับที่ 6 - GUI ไม่ได้จับมันเพราะ มันไม่สอดคล้องกับโดเมน ณ จุดที่เขาส่งคำสั่งของเขา - ในกรณีนี้คุณมี 'การตรวจสอบความล้มเหลว' เป็นส่วนหนึ่งของตรรกะโดเมนของคุณและคุณจะส่งคืนเหตุการณ์ความล้มเหลวที่เกี่ยวข้อง

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

บ่อยครั้งที่คุณมีเหตุการณ์ที่กำหนดเองซึ่งหมายถึงความล้มเหลวของคำสั่งหลายประเภทและเป็นเหตุการณ์ที่คุณสมัครรับข้อมูลจากมุมมองของเว็บเซิร์ฟเวอร์

ในระบบที่เรากำลังทำงานอยู่ที่เรากำลังทำตอบสนองการร้องขอที่มีคำสั่ง / เหตุการณ์ที่เกิดขึ้นในช่วง MassTransit + RabbitMQ ข้อความบัส + นายหน้าและเรามีเหตุการณ์ในโดเมนนี้โดยเฉพาะ (การสร้างแบบจำลองขั้นตอนการทำงานในส่วน) InvalidStateTransitionErrorที่มีชื่อ คำสั่งส่วนใหญ่ที่พยายามเคลื่อนไปตามขอบในกราฟสถานะอาจทำให้เหตุการณ์นี้เกิดขึ้น ในกรณีของเราเรากำลังสร้างโมเดล GUI หลังจากกระบวนทัศน์ที่สอดคล้องกันในที่สุดและดังนั้นเราจึงส่งผู้ใช้ไปยังหน้า 'คำสั่งที่ยอมรับ' และหลังจากนั้นให้เว็บเซิร์ฟเวอร์ปรับปรุงมุมมองผ่านการสมัครรับข้อมูลเหตุการณ์ มันควรจะกล่าวว่าเรากำลังทำกิจกรรมการจัดหาในรากรวม (และจะทำเพื่อ sagas เช่นกัน)

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

ฉันสามารถ recommand ดูทั้งสองนำเสนอเกี่ยวกับ DDD จากผู้พัฒนานอร์เวย์ประชุม 2011และยังนำเสนอของเกร็กที่Öredev 2010

ไชโย Henke

แก้ไข: ลิงก์ WaybackMachine: http://devlicio.us/blogs/billy_mccafferty/archive/2009/02/17/a-response-to-validation-in-a-ddd-world.aspx

ไม่มีคำตอบ pat

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

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