เหตุใดจึงต้องแยกชั้นเรียน CommandHandler พร้อมหมายเลขอ้างอิง () แทนวิธีการจัดการใน Command เอง

ฉันมีส่วนหนึ่งของรูปแบบ CQRS ที่นำมาใช้โดยใช้สถาปัตยกรรม S # arpดังนี้:

public class MyCommand
{
    public CustomerId { get; set; }

    // some other fields
}

public class MyCommandHandler<MyCommand> : ICommandHandler<MyCommand, CommandResult>
{
    Handle(MyCommand command)
    {
        // some code for saving Customer entity

        return CommandResult.Success;
    }
}

ฉันสงสัยว่าทำไมไม่เพียงแค่มีคลาสCommandที่มีทั้งข้อมูลและวิธีการจัดการ? มันเป็นข้อดีของการทดสอบที่คุณต้องทดสอบตรรกะการจัดการคำสั่งแยกต่างหากจากคุณสมบัติคำสั่งหรือไม่? หรือมันเป็นบางอย่างที่ต้องการทางธุรกิจบ่อยครั้งที่คุณจำเป็นต้องมีคำสั่งอย่างใดอย่างหนึ่งจัดการโดยการใช้งานที่แตกต่างกันของICommandHandler<MyCommand, CommandResult>?

ขำ ๆ คำถามนี้ทำให้ฉันนึกถึงบทสนทนาเดียวกับที่ฉันมีกับหนึ่งในวิศวกรของเราเกี่ยวกับห้องสมุดการสื่อสารที่ฉันทำงานอยู่

แทนที่จะเป็นคำสั่งฉันมีคลาสขอแล้วฉันก็มี RequestHandler การออกแบบนั้นเหมือนกับสิ่งที่คุณกำลังอธิบาย ฉันคิดว่าส่วนหนึ่งของความสับสนที่คุณมีคือคุณเห็นคำภาษาอังกฤษ "คำสั่ง" และคิดว่า "คำกริยาการกระทำ ... ฯลฯ " ทันที

แต่ในการออกแบบนี้ให้คิดว่า Command (หรือ Request) เป็นตัวอักษร หรือสำหรับผู้ที่ไม่ทราบว่าบริการไปรษณีย์คืออะไรคิดอีเมล มันเป็นเพียงเนื้อหาแยกออกจากวิธีการที่เนื้อหาควรจะดำเนินการ

ทำไมคุณถึงทำเช่นนี้? ในกรณีที่ง่ายที่สุดของรูปแบบคำสั่งไม่มีเหตุผลและคุณสามารถให้คลาสนี้ทำงานได้โดยตรง อย่างไรก็ตามการทำ decoupling ในแบบของคุณนั้นสมเหตุสมผลถ้าการกระทำ / คำสั่ง / คำขอของคุณต้องเดินทางไกล ตัวอย่างเช่นข้ามซ็อกเก็ตหรือไพพ์หรือระหว่างโดเมนและโครงสร้างพื้นฐาน หรืออาจจะอยู่ในสถาปัตยกรรมของคุณคำสั่งของคุณจะต้องคงอยู่ (เช่นตัวจัดการคำสั่งสามารถทำ 1 คำสั่งได้ในแต่ละครั้งเนื่องจากเหตุการณ์บางอย่างของระบบคำสั่ง 200 คำสั่งมาถึงและหลังจากกระบวนการ 40 ครั้งแรกได้รับการปิด) ในกรณีดังกล่าวการมีคลาสข้อความอย่างเดียวอย่างง่ายมันจะกลายเป็นเรื่องง่ายมากที่จะทำให้เป็นอนุกรมส่วนของข้อความใน JSON / XML / binary / อะไรก็ตามและส่งมันลงท่อไปจนกว่าตัวจัดการคำสั่งของมันพร้อมที่จะประมวลผล

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

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

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

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

นอกจากนี้ nitpick เล็กน้อย เพียงเพราะมันมี Command ในชื่อไม่ได้ทำให้มันเป็นส่วนหนึ่งของ CQRS นั่นเป็นเรื่องพื้นฐานที่สำคัญกว่ามาก โครงสร้างชนิดนี้สามารถให้บริการทั้งคำสั่งและเป็นคิวรีแม้ในเวลาเดียวกัน