ข้อยกเว้นใน DDD

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

public function doIt(UserData $userData)
{
    $user = $this->userRepository->byEmail($userData->email());
    if ($user) {
        throw new UserAlreadyExistsException();
    }

    $this->userRepository->add(
        new User(
            $userData->email(),
            $userData->password()
        )
    );
}

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

วิธีที่ดีที่สุดสำหรับสิ่งนี้คืออะไร?

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

แบบจำลองโลหิตจางสามารถสร้างความรู้สึกได้อย่างมากมายสำหรับนักพัฒนาที่เพิ่งเริ่มใช้ DDD คุณสร้างUserแบบจำลองและแบบEmailMustBeUnqiueRuleที่ได้รับการฉีดด้วยข้อมูลที่จำเป็นในการตรวจสอบอีเมล ง่าย สง่า ปัญหาคือว่า "ชนิด" ความคิดนี้เป็นขั้นตอนพื้นฐานในธรรมชาติ ไม่ใช่ DDD สิ่งที่เกิดขึ้นคือคุณถูกทิ้งให้อยู่กับโมดูลที่Rulesห่อหุ้มและห่อหุ้มอย่างเรียบร้อยหลายสิบครั้ง แต่สิ่งเหล่านี้ปราศจากบริบทโดยสิ้นเชิงจนถึงจุดที่ไม่สามารถเปลี่ยนได้อีกต่อไปเพราะมันไม่ชัดเจนเมื่อมีการบังคับใช้ มันสมเหตุสมผลไหม มันอาจจะเห็นได้ชัดว่าตัวเอง EmailMustBeUnqiueRuleจะถูกนำไปใช้ในการสร้างของUserแต่สิ่งที่เกี่ยวกับUserIsInGoodStandingRule? อย่างช้า ๆ แต่แน่นอนการแยกเป็นเมล็ดของRulesจากบริบทของพวกเขาทำให้คุณมีระบบที่เข้าใจยาก (และไม่สามารถเปลี่ยนแปลงได้) ควรห่อหุ้มกฎเฉพาะเมื่อการกระทืบ / การประมวลผลที่แท้จริงเกิดขึ้นจริงดังนั้นรูปแบบของคุณจะเริ่มหลวมโฟกัส

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

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

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

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

ตัวอย่างเช่นเอนทิตีใช้วิธีการที่แสดงถึงกฎเกณฑ์ทางธุรกิจในขณะที่ use-cases ใช้กฎเฉพาะสำหรับแอปพลิเคชันของคุณ

หากการสร้างบริการอีเมลของคุณเหมือนกับ Gmail อาจให้เหตุผลว่ากฎ "ผู้ใช้ควรมีอีเมลที่ไม่ซ้ำ" เป็นกฎทางธุรกิจ

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

เพื่อความปลอดภัย aditional คุณสามารถบังคับใช้กฎนี้ในที่เก็บของคุณ