DDD - ที่เก็บของรูทรวมจัดการการรวมการบันทึกหรือไม่?

ฉันใช้วิธีที่คล้ายกับ DDD สำหรับโมดูลกรีนฟิลด์ของแอปพลิเคชันที่มีอยู่ ไม่ใช่ DDD 100% เนื่องจากสถาปัตยกรรม แต่ฉันพยายามใช้แนวคิด DDD บางอย่าง ฉันมีบริบท จำกัด (ผมคิดว่าเป็นระยะที่เหมาะสม - ฉันยังคงเรียนรู้เกี่ยวกับ DDD) ประกอบด้วยสองหน่วยงาน: และConversation Messageการสนทนาเป็นรากฐานเนื่องจากข้อความไม่มีอยู่โดยไม่มีการสนทนาและข้อความทั้งหมดในระบบเป็นส่วนหนึ่งของการสนทนา

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

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

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

กลุ่มของ 2 เอนทิตีที่คุณกล่าวถึงไม่ใช่บริบทที่ถูกผูกมัด - มันอาจจะเป็นการรวม แต่ละ Aggregate มี Aggregate Root ซึ่งเป็น Entity ที่ทำหน้าที่เป็น entry point เดียวไปยัง Aggregate สำหรับวัตถุอื่นทั้งหมด ดังนั้นไม่มีความสัมพันธ์โดยตรงระหว่างเอนทิตีและเอนทิตีอื่นในการรวมอื่นที่ไม่ใช่รูทการรวม

จำเป็นต้องมีที่เก็บเพื่อเก็บเอนทิตีที่ไม่สามารถหาได้ง่ายจากการเคลื่อนที่ของวัตถุอื่น ที่เก็บมักจะมี Aggregate Roots แต่สามารถมี Repositories ของ Entity ได้เช่นกัน

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

ConversationRepository จะมีบทบาทในการคงข้อความไว้ แต่ไม่ใช่บทบาทโดยตรงดังที่คุณพูดถึง ดังนั้นไม่มี AddMessage () บน ConversationRepository (วิธีการนั้นค่อนข้างเป็นของ Conversation เอง) แต่ทุกครั้งที่ Repository จะเก็บบทสนทนาเอาไว้คุณควรเก็บข้อความไว้ในเวลาเดียวกันแทนที่จะเป็นการดีถ้าคุณใช้เฟรมเวิร์ก ORM เช่น (N) Hibernate โดยใช้ ad hoc SQL หากคุณเลือกเป็นต้น

คุณสามารถสร้างConversationServiceและฉีดIConversationRepositoryและIMessageRepositoryใน Constructor ใช้แหล่งเก็บข้อมูลสำหรับการดำเนินการ CRUD อย่างง่ายและบริการสำหรับทุกสิ่ง (แคชแคชการบันทึกตรรกะ ฯลฯ )