การใช้ DDD: ผู้ใช้และการอนุญาต

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

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

• การดำเนินการกับโดเมนจะถูกเรียกพร้อมกับบทบาทที่เกี่ยวข้องเป็นพารามิเตอร์: เช่น:

  ModeratePost( ..., moderator);

• วิธีการของวัตถุโดเมนตรวจสอบว่าอินสแตนซ์ของโมเดอเรเตอร์ที่กำหนดไม่ใช่โมฆะ (อินสแตนซ์ของโมเดอเรเตอร์จะเป็นโมฆะถ้าผู้ใช้ที่ถามจากบริบทผู้ใช้และบริบทไม่มีบทบาทผู้ดูแล)

• ในกรณีหนึ่งจะทำการตรวจสอบเพิ่มเติมก่อนที่จะแก้ไขโพสต์:

  if (forum.IsModeratedby(moderator))

คำถามของฉันคือ:

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

• การนำไปใช้ตามบทบาทในหนังสือเล่มนี้ค่อนข้างตรงไปตรงมา: เมื่อ Moderator เป็นโดเมนหลักพยายามแปลง userId ปัจจุบันเป็น Moderator หรือเป็นผู้เขียนเมื่อต้องการ บริการจะตอบกลับด้วยอินสแตนซ์ที่เหมาะสมหรือเป็นโมฆะหากผู้ใช้ไม่มีบทบาทที่จำเป็น อย่างไรก็ตามฉันไม่สามารถเห็นได้ว่าฉันจะปรับให้เข้ากับรูปแบบการรักษาความปลอดภัยที่ซับซ้อนมากขึ้นได้อย่างไร โครงการปัจจุบันของเราที่ฉันกำลังดำเนินการอยู่นั้นมีรูปแบบที่ค่อนข้างซับซ้อนกับกลุ่ม ACL ฯลฯ

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

โดยการถามบริบท Identity and Access สำหรับอินสแตนซ์ OwnerOrEditor รู้สึกไม่ถูกต้องและฉันจะจบลงด้วยคลาสที่เกี่ยวข้องกับความปลอดภัยมากขึ้นในโดเมนหลัก นอกจากนี้ฉันจะต้องผ่านไม่ใช่ userId เท่านั้น แต่ตัวระบุของทรัพยากรที่มีการป้องกัน (id ของโพสต์ฟอรัม ฯลฯ ) ไปยังบริบทความปลอดภัยซึ่งอาจไม่ควรสนใจสิ่งเหล่านี้ (ถูกต้องหรือไม่? )

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

ฉันได้อ่านที่ไหนสักแห่ง (และฉันมักจะเห็นด้วยกับมัน) ว่าสิ่งเหล่านี้เกี่ยวข้องกับการอนุญาตไม่ควรเป็นส่วนหนึ่งของโดเมนหลักยกเว้นว่าการรักษาความปลอดภัยและการอนุญาตเป็นโดเมนหลักเอง กฎอย่างง่าย ๆ เช่นเดียวกับที่ระบุไว้ข้างต้นแสดงให้เห็นถึงการรักษาความปลอดภัยเป็นส่วนหนึ่งของโดเมนหลักหรือไม่?

บางครั้งก็ยากที่จะแยกแยะความแตกต่างระหว่างกฎการควบคุมการเข้าถึงจริงและค่าคงที่โดเมนในการควบคุมการเข้าถึง

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

assert (forum.IsModeratedBy(moderator))ตัวอย่างของ Vaughn Vernon น่าจะอยู่นอกโดเมน แต่ไม่เป็นไปได้เสมอไป

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

หากมี Security BC และคุณต้องการให้จัดการกับตรรกะนั้นก็ไม่จำเป็นต้องรู้ว่าฟอรัมมีรายละเอียดอะไร แต่:

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

การพิสูจน์ตัวตนและการอนุญาตเป็นตัวอย่างที่ไม่ดีสำหรับ DDD

ไม่มีสิ่งเหล่านี้เป็นส่วนหนึ่งของโดเมนเว้นแต่ว่า บริษัท ของคุณจะสร้างผลิตภัณฑ์รักษาความปลอดภัย

ข้อกำหนดของธุรกิจหรือโดเมนคือหรือควรเป็น "ฉันต้องการการรับรองความถูกต้องตามบทบาท"

จากนั้นคุณตรวจสอบบทบาทก่อนเรียกใช้ฟังก์ชันโดเมน

ที่ที่คุณมีข้อกำหนดที่ซับซ้อนเช่น 'ฉันสามารถแก้ไขโพสต์ของตัวเอง แต่ไม่ใช่คนอื่น' ตรวจสอบให้แน่ใจว่าโดเมนของคุณแยกฟังก์ชันแก้ไขออกเป็นEditOwnPost()และEditOthersPost()เพื่อให้คุณมีฟังก์ชั่นที่ง่ายในการทำแผนที่บทบาท

คุณยังสามารถแยกฟังก์ชันการทำงานออกเป็น Domain Objects เช่น Poster.EditPost()และModerator.EditPost()นี่เป็นวิธีการแบบ OOP ที่มากขึ้นถึงแม้ว่าตัวเลือกของคุณอาจขึ้นอยู่กับว่าวิธีการของคุณอยู่ในบริการโดเมนหรือ Domain Object

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

PostController : ApiController
{
    [Authorize(Roles = "User")]
    public void EditOwnPost(string postId, string newContent)
    {
        this.postDomainService.EditOwnPost(postId, string newContent);
    }

    [Authorize(Roles = "Moderator")]
    public void EditOtherPost(string postId, string newContent)
    {
        this.postDomainService.EditOtherPost(postId, string newContent);
    }
}

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

โดเมนตระหนักถึงความแตกต่างของการกระทำ แต่ความต้องการของการรักษาความปลอดภัยก็คือว่า"การทำงานสามารถถูก จำกัด โดยบทบาท"

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