คำถามติดแท็ก domain-driven-design

การออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD) เป็นวิธีการพัฒนาซอฟต์แวร์สำหรับความต้องการที่ซับซ้อนโดยการเชื่อมต่อการใช้งานกับรูปแบบการพัฒนา

2
ไปยังที่เก็บหรือไม่ไปยังที่เก็บ
เมื่อครั้งแรกที่ฉันได้เรียนรู้เกี่ยวกับการออกแบบการขับเคลื่อนด้วยโดเมนฉันยังได้รับการแนะนำให้รู้จักกับที่เก็บและรูปแบบการทำงานที่ครั้งหนึ่งดูเหมือนจะเป็นอันดับต้น ๆ สำหรับเด็กสุดเท่ห์ที่ทำให้แบบสอบถาม SQL เช่น cavemans เทียบกับฐานข้อมูล ยิ่งฉันเข้าสู่หัวข้อนั้นมากเท่าไหร่ฉันก็ยิ่งรู้ว่าพวกเขาไม่จำเป็นอีกต่อไปเพราะORMsเช่นEFและNHibernateที่ใช้ทั้งสองหน่วยงานและพื้นที่เก็บข้อมูลไว้ใน API เดียวที่เรียกว่าเซสชันหรือบริบท ตอนนี้ฉันไม่แน่ใจว่าจะทำอย่างไร เพื่อเก็บหรือไม่ไปยังที่เก็บ ผมเข้าใจโต้แย้งว่าแนวคิดดังกล่าวรั่วเพียงสิ่งที่มากกว่าซับซ้อนขณะที่การเพิ่มอะไรอย่างที่อาจลดความซับซ้อนของการเข้าถึงข้อมูล แต่ก็ไม่ได้รู้สึกขวาคู่ทุกด้านที่เป็นไปได้ของการประยุกต์ใช้ของฉันไปเช่นEntity Framework โดยปกติฉันทำตามคำแนะนำง่ายๆ: เลเยอร์โดเมนคือหัวใจของระบบที่มีเอนทิตี, บริการ, ที่เก็บ ... ชั้นโครงสร้างพื้นฐานให้การใช้งานของส่วนต่อประสานโดเมนที่เกี่ยวข้องกับโครงสร้างพื้นฐานเช่นไฟล์ฐานข้อมูลโปรโตคอล ชั้นแอพลิเคชันเป็นเจ้าภาพรากองค์ประกอบที่เชื่อมโยงสิ่งต่างๆและประสานทุกอย่าง โซลูชันของฉันมักจะมีลักษณะเช่นนี้: Domain.Module1 Domain.Module2 IModule2Repo IModule2Service Module2 Infrastructure.Persistence Repositories EntityFrameworkRepositoryBase MyApp Boostrapper -> inject EntityFrameworkRepositoryBase into IRepository etc. ฉันรักษาเลเยอร์โดเมนของฉันให้สะอาดโดยใช้สิ่งIRepository<'T>ที่เป็นข้อกังวลเกี่ยวกับโดเมนไม่ขึ้นอยู่กับสิ่งอื่นใดที่บอกวิธีเข้าถึงข้อมูล เมื่อตอนนี้ฉันจะทำให้การใช้งานที่เป็นรูปธรรมของIModule2Serviceที่ต้องการเข้าถึงข้อมูลฉันจะต้องฉีดDbContextและโดยสิ่งนี้เชื่อมต่อโดยตรงกับชั้นโครงสร้างพื้นฐาน ( มาที่โครงการ Visual Studio สิ่งนี้อาจทำให้ยุ่งยากเพราะการอ้างอิงแบบวงกลม! ) นอกจากนี้สิ่งที่สามารถเป็นทางเลือกให้กับศูนย์รับฝากและงานfucktons ? CQRS? …

2
การออกแบบ Domain Driven ที่เทียบเท่ากับภาษาโปรแกรมที่ใช้งานได้
ฉันชอบความคิดเกี่ยวกับการออกแบบที่ขับเคลื่อนด้วยโดเมน แต่ในขณะที่ฉันกำลังเรียนรู้ Go ฉันสงสัยว่ามี DDD ที่เทียบเท่ากับภาษาที่มีประสิทธิภาพมากกว่าหรือไม่

1
ORM POCOs แทนที่โดเมนหรือไม่
นี่ค่อนข้างคล้ายกับคำถามนี้แต่กว้างขึ้น โดยทั่วไปแล้วด้วย ORMs เช่น EF 4.1 ที่รองรับ POCO ตอนนี้มันสมเหตุสมผลหรือไม่ที่จะให้หน่วยงานโดเมนของคุณเป็นวัตถุที่ยังคงอยู่ในฐานข้อมูลของคุณ ด้วย ORM ที่เก่ากว่าเช่น EF 4 หรือ Linq-to-SQL วัตถุ "ฐานข้อมูล" ของคุณจะถูกสร้างขึ้นโดยอัตโนมัติและเชื่อมต่อกับฐานข้อมูลของคุณอย่างแน่นหนาและดังนั้นสำหรับแอปพลิเคชันที่ไม่น่าสนใจ นำไปทำงาน เป็นความคิดที่มี ORM ที่ใหม่กว่าเพียงแค่สร้างเอนทิตีโดเมนที่มีประสิทธิภาพแล้วมี data-layer ที่ให้การแม็พระหว่างเอนทิตีโดเมนดังกล่าวกับ DBMS ของคุณหรือไม่ ในการเขียนที่ฉันรู้สึกว่านี่เป็นเป้าหมายเสมอแต่ไม่สามารถทำได้อย่างง่ายดายด้วยเครื่องมือที่มีอยู่อย่างน้อยไม่ใช่ในโลก NET

1
วิธีการนำแนวคิดของ DDD ไปใช้กับโค้ดจริง คำถามเฉพาะภายใน
ฉันกำลังศึกษา DDD อยู่และขณะนี้ฉันกำลังดิ้นรนเพื่อหาวิธีที่จะใช้แนวคิดในโค้ดจริง ฉันมีประสบการณ์เกี่ยวกับ N-Tier ประมาณ 10 ปีดังนั้นจึงเป็นไปได้อย่างมากว่าเหตุผลที่ฉันต้องดิ้นรนคือแบบจำลองทางจิตของฉันมีความสัมพันธ์กับการออกแบบนั้นมากเกินไป ฉันสร้างแอปพลิเคชันเว็บ Asp.NET และฉันเริ่มต้นด้วยโดเมนง่ายๆ: แอปพลิเคชันตรวจสอบเว็บ ที่ต้องการ: ผู้ใช้จะต้องสามารถลงทะเบียน Web App ใหม่เพื่อตรวจสอบ แอปพลิเคชันเว็บมีชื่อที่จดจำง่ายและชี้ไปที่ URL แอปพลิเคชันบนเว็บจะทำการสำรวจสถานะเป็นระยะ ๆ (ออนไลน์ / ออฟไลน์) แอปพลิเคชันเว็บจะสำรวจความคิดเห็นของเวอร์ชันปัจจุบันเป็นระยะ (คาดว่าแอพพลิเคชั่นเว็บจะมี "/version.html" ซึ่งเป็นไฟล์ที่ประกาศรุ่นของระบบในมาร์กอัพที่เฉพาะเจาะจง) ข้อสงสัยของฉันส่วนใหญ่เกี่ยวกับการแบ่งหน้าที่ความรับผิดชอบการหาสถานที่ที่เหมาะสมสำหรับแต่ละสิ่ง (การตรวจสอบความถูกต้องกฎเกณฑ์ทางธุรกิจ ฯลฯ ) ด้านล่างฉันเขียนโค้ดและเพิ่มความคิดเห็นพร้อมคำถามและข้อควรพิจารณา กรุณาวิพากษ์วิจารณ์และให้คำแนะนำ ขอบคุณล่วงหน้า! MODEL DOMAIN สร้างแบบจำลองเพื่อแค็ปซูลกฎธุรกิจทั้งหมด // Encapsulates logic for creating and validating Url's. // Based on "Unbreakable …

4
วิธี DDD ในการดำเนินงาน CRUD ขั้นพื้นฐานในแอปพลิเคชันโดเมนเป็นศูนย์กลางที่ซับซ้อน
บริษัท ของฉันกำลังเขียนเว็บแอปพลิเคชันของเราใหม่ตั้งแต่ต้น เป็นแอปพลิเคชันระดับองค์กรขนาดใหญ่ที่มีโดเมนที่ซับซ้อนในอุตสาหกรรมการเงิน เรากำลังใช้ ORM (Entity framework) เพื่อคงอยู่ ในสาระสำคัญครึ่งหนึ่งของศูนย์แอปพลิเคชันของเรามีการรวบรวมข้อมูลดิบจากผู้ใช้เก็บไว้และอีกครึ่งหนึ่งของแอปพลิเคชันที่มีตรรกะโดเมนจริงของเราส่วนใหญ่จะใช้ข้อมูลดิบนั้นเพื่อสร้างภาพโดเมนของเราซึ่งแตกต่างอย่างมากจากต้นฉบับ อินพุตดิบและส่งผ่านไปยังเครื่องยนต์ calc เรียกใช้ calcs และแยกผลลัพธ์ซึ่งจะแสดงต่อผู้ใช้ ในวิธี DDD โดยใช้เลเยอร์ดูเหมือนว่าการดำเนินการ CRUD จะผ่านชั้นโดเมน แต่อย่างน้อยในกรณีของเราสิ่งนี้ดูเหมือนจะไม่สมเหตุสมผล เมื่อผู้ใช้ไปที่หน้าจอแก้ไขเพื่อเปลี่ยนบัญชีการลงทุนเช่นเขตข้อมูลบนหน้าจอเป็นเขตข้อมูลที่แน่นอนที่เก็บไว้ในฐานข้อมูลไม่ใช่การแทนโดเมนที่ใช้ในการคำนวณในภายหลัง เหตุใดฉันจึงต้องโหลดการแทนโดเมนของบัญชีการลงทุนเมื่อหน้าจอแก้ไขต้องการการแสดงฐานข้อมูล (อินพุตดิบ) หลังจากที่ผู้ใช้คลิก "เสร็จสิ้น" บนหน้าจอบัญชีการลงทุนและมีการดำเนินการ POST กับคอนโทรลเลอร์ตอนนี้ผู้ควบคุมมีการแสดงฐานข้อมูลที่แน่นอนของบัญชีการลงทุนที่ต้องการบันทึก แต่ด้วยเหตุผลบางอย่างฉันควรโหลดการแทนโดเมนเพื่อทำการแก้ไขแทนการแมปโมเดลของคอนโทรลเลอร์โดยตรงกับโมเดลฐานข้อมูล (โมเดลเอนทิตีกรอบ) ดังนั้นโดยพื้นฐานแล้วฉันกำลังแมปโมเดลข้อมูลกับโมเดลโดเมนดังนั้นจึงสามารถแมปกลับไปยังตัวแบบข้อมูลเพื่อคงอยู่ได้ มันสมเหตุสมผลแค่ไหน?

3
มันเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่สำหรับคำนิยามออบเจ็กต์ API ที่มีรหัสอ้างอิงบุคคลที่สามเป็นคุณสมบัติหรือไม่
แบบนี้: Campaign: type: object properties: id: type: string description: "A GUID identifier" referenceId: type: string description: "A consumers identifier they have used to map their own systems logic to this object." name: type: string description: "'Great Campaign 2017' as an example" ผมกังวลเกี่ยวกับreferenceid โดเมนระบบเป็นแพลตฟอร์มที่รวมเข้ากับบุคคลที่สามได้หลายวิธีผ่านการส่งออกข้อมูลและการนำเข้ารูปแบบต่างๆ (xml, excel) เป็นผู้ใหญ่พอที่จะอนุญาตให้บุคคลที่ 3 รวมกับระบบของเราผ่าน API และการออกแบบของ …

4
วิธีกำหนดขอบเขตของบริบทที่มีขอบเขตอย่างชัดเจน
หลังจากอ่านและค้นคว้า DDD มาหนึ่งเดือนฉันตัดสินใจเริ่มโครงการของตัวเองและสร้าง DDD ด้วยบริบทที่ล้อมรอบเหล่านี้> ลูกค้า ผลิตภัณฑ์ สั่งซื้อ การเรียกเก็บเงิน แต่ละบริบทที่ถูกล้อมรอบมี API ส่วนที่เหลือเป็นเลเยอร์การนำเสนอเลเยอร์โดเมนชั้นถาวร จนถึงตอนนี้โค้ดก็ทำงานได้อย่างราบรื่น แต่มาจากโลกใบใหญ่ที่ฉันยังคงพยายามหาข้อมูลต่อไปนี้: เมื่อฉันต้องการสร้างลูกค้าใหม่ออกใบแจ้งหนี้ใหม่สร้างคำสั่งซื้อใหม่ที่ฉันต้องการตัวอย่างเช่นรายการการเข้าถึงของประเทศ ฉัน: ก) สร้างรายชื่อประเทศในแต่ละปีก่อนคริสต์ศักราช b) สร้างประเทศ BC -> API และใช้เพื่อรับรายชื่อประเทศที่มี c) ใช้ API ของบุคคลที่สามและดึงข้อมูลผ่านเลเยอร์ anticoruption ในแต่ละ BC เมื่อรวมเข้ากับ API ของบุคคลที่สามโดยใช้เลเยอร์ต่อต้านการคอร์รัปชั่นหรือเลเยอร์อะแดปเตอร์จะต้องมีข้อมูลใดบ้างในโมเดลโดเมนของฉัน ตัวอย่างเช่นถ้าฉันต้องการรวม zendesk API กับ Client BC ฉันต้องการเพียง ticketID ในโดเมนของฉันหรือฉันต้องดึงข้อมูลทั้งหมดจาก Zendesk ที่ฉันต้องการเข้าถึงและใช้งานใน Client BC หรือไม่ หากแอป MVC …

2
ควรระบุ ID ธุรกิจที่เป็นที่รู้จักกันดีของกิจการด้วยประเภทเฉพาะใน DDD / OOP หรือไม่
ในแง่การปฏิบัติมันหมายถึงการใช้กำหนดเอง (ไม่เปลี่ยนรูป) classมากกว่าstringหรือบางประเภทดั้งเดิมอื่น ๆ ตัวอย่าง: สำนักพิมพ์: หมายเลขหนังสือมาตรฐานสากล การเงิน: หมายเลขประจำตัวของหลักทรัพย์ระหว่างประเทศ ข้อดี: สามารถมั่นใจได้ว่ารูปแบบของตัวระบุ กลายเป็นสมาชิกชั้นหนึ่งของโมเดล ข้อเสีย: เพิ่มแรงเสียดทานติดตา (เช่น Entity Framework) รหัสเพิ่มเติม

4
สร้างแบบจำลองความสัมพันธ์กับ DDD (หรือมีเหตุผล)?
นี่คือข้อกำหนดที่ง่ายขึ้น: ผู้ใช้สร้างQuestionที่มีหลายAnswers Questionต้องมีอย่างน้อยหนึ่งAnswerรายการ การชี้แจง: คิดQuestionและAnswerในการทดสอบ : มีคำถามหนึ่งข้อ แต่มีหลายคำตอบซึ่งมีเพียงไม่กี่ข้อที่ถูกต้อง ผู้ใช้คือนักแสดงที่กำลังเตรียมการทดสอบนี้ดังนั้นเขาจึงสร้างคำถามและคำตอบ ฉันพยายามจำลองตัวอย่างง่ายๆนี้เพื่อ 1) จับคู่โมเดลชีวิตจริง 2) แสดงรหัสด้วยดังนั้นเพื่อลดการใช้ผิดและข้อผิดพลาดที่อาจเป็นไปได้และให้คำแนะนำแก่นักพัฒนาเกี่ยวกับวิธีใช้โมเดล คำถามที่เป็นนิติบุคคลในขณะที่คำตอบคือวัตถุที่คุ้มค่า คำถามถือคำตอบ จนถึงตอนนี้ฉันมีวิธีแก้ปัญหาที่เป็นไปได้เหล่านี้ [A]ภายในโรงงานQuestion แทนที่จะสร้างAnswerด้วยตนเองเราสามารถโทร: Answer answer = question.createAnswer() answer.setText(""); ... ที่จะสร้างคำตอบและเพิ่มลงในคำถาม จากนั้นเราสามารถจัดการคำตอบได้โดยตั้งค่าคุณสมบัติ ด้วยวิธีนี้เฉพาะคำถามเท่านั้นที่สามารถสร้างคำตอบได้ นอกจากนี้เราป้องกันไม่ให้มีคำตอบโดยไม่มีคำถาม แต่เราไม่ได้มีการควบคุมมากกว่าการสร้างคำตอบเป็นที่ hardcoded Questionใน นอกจากนี้ยังมีปัญหาหนึ่งกับ 'ภาษา' ของรหัสด้านบน ผู้ใช้คือคนที่สร้างคำตอบไม่ใช่คำถาม โดยส่วนตัวแล้วฉันไม่ชอบที่เราจะสร้างวัตถุที่มีคุณค่าและขึ้นอยู่กับนักพัฒนาเพื่อเติมให้เต็มด้วยค่า - เขาจะแน่ใจได้อย่างไรว่าจะต้องเพิ่มอะไรบ้าง [B]คำถามจากโรงงานใช้ # 2 บางคนบอกว่าเราควรมีวิธีนี้ในQuestion: question.addAnswer(String answer, boolean correct, int level....); เช่นเดียวกับวิธีแก้ไขปัญหาข้างต้นวิธีนี้ใช้ข้อมูลที่จำเป็นสำหรับคำตอบและสร้างรายการที่จะถูกเพิ่มลงในคำถามด้วย …

2
DDD: วัตถุที่ไม่เปลี่ยนรูปสามารถเป็นเอนทิตีได้หรือไม่
ฉันได้อ่านโพสต์นับไม่ถ้วนเกี่ยวกับความแตกต่างระหว่างเอนทิตีและออบเจ็กต์ค่าและในขณะที่ฉันคิดว่าอย่างน้อยที่สุดฉันเข้าใจว่าแนวคิดทั้งสองแตกต่างกันอย่างไรปรากฏว่าในผู้เขียนบทความบางคนพิจารณาว่า มีการเปลี่ยนรูป (ดังนั้นสถานะจะไม่เปลี่ยนแปลงอย่างน้อยภายในรูปแบบโดเมนนั้น) คุณเห็นด้วยหรือไม่ว่าหากสถานะของวัตถุจะไม่เปลี่ยนแปลงภายในโมเดลโดเมนใด ๆ วัตถุนี้จะไม่เป็นนิติบุคคลหรือไม่ ทำไม?

4
การตรวจสอบความสอดคล้องของธุรกรรมด้วย DDD
ฉันเริ่มต้นด้วย DDD และเข้าใจว่ามีการใช้รากรวมเพื่อรับรองความมั่นคงข้ามชาติ เราไม่ควรแก้ไขการรวมหลายรายการในบริการแอปพลิเคชันเดียว ฉันต้องการทราบวิธีจัดการกับสถานการณ์ต่อไปนี้ ฉันมีรูทรวมที่เรียกว่าผลิตภัณฑ์ นอกจากนี้ยังมีรูทรวมที่เรียกว่ากลุ่ม ทั้งสองมีรหัสและสามารถแก้ไขได้อย่างอิสระ ผลิตภัณฑ์หลายรายการสามารถชี้ไปที่กลุ่มเดียวกัน ฉันมีบริการแอปพลิเคชันที่สามารถเปลี่ยนกลุ่มของผลิตภัณฑ์: ProductService.ChangeProductGroup(string productId, string groupId) ตรวจสอบกลุ่มที่มีอยู่ รับผลิตภัณฑ์จากพื้นที่เก็บข้อมูล ตั้งค่ากลุ่ม เขียนผลิตภัณฑ์กลับไปที่ที่เก็บ ฉันยังมีบริการแอปพลิเคชันที่สามารถลบกลุ่มได้: GroupService.DeleteGroup(string groupId) 1. รับผลิตภัณฑ์จากที่เก็บซึ่ง groupId ถูกตั้งค่าเป็น groupId ที่ระบุตรวจสอบให้แน่ใจว่าการนับเป็น 0 หรือยกเลิก 2. ลบกลุ่มจากที่เก็บกลุ่ม 3. บันทึกการเปลี่ยนแปลง คำถามของฉันคือสถานการณ์ต่อไปนี้จะเกิดอะไรขึ้นถ้า: ใน ProductService.ChangeProductGroup เราจะตรวจสอบกลุ่มที่มีอยู่ (เช่นนั้น) จากนั้นหลังจากการตรวจสอบนี้ผู้ใช้ที่แยกต่างหากจะลบ productGroup (ผ่าน GroupService.DeleteGroup อื่น) ในกรณีนี้เราตั้งค่าการอ้างอิงถึงผลิตภัณฑ์ที่เพิ่งถูกลบ? นี่เป็นข้อบกพร่องในการออกแบบของฉันที่ฉันควรใช้การออกแบบโดเมนที่แตกต่างกัน (เพิ่มองค์ประกอบเพิ่มเติมถ้าจำเป็น) หรือฉันจะต้องใช้การทำธุรกรรม?

2
เราควรเลียนแบบเอนทิตีและวัตถุที่มีค่าเมื่อทำ DDD หรือไม่
หลังจากที่อ่านไม่กี่ บทความเกี่ยวกับnewable VS ฉีดวัตถุและวิธีการแนวความคิดเหล่านี้เกี่ยวข้องกับ DDD บริการหน่วยงานและวัตถุค่าฉันถูกทิ้งให้อยู่กับข้อสงสัยบางอย่างเกี่ยวกับการใช้ newables ในรหัสของฉันโดยเฉพาะอย่างยิ่งในการทดสอบหน่วยของฉัน ผู้สมัครหลักสำหรับ newables คือ Entities และ Value objects หมายถึงแทนที่จะฉีดการขึ้นต่อกันเหล่านี้ไปยังอ็อบเจกต์อื่นเราควรnewเป็นเพียงตัวอย่างของอ็อบเจกต์เหล่านี้และใช้มันโดยตรงในโค้ด อย่างไรก็ตามแนวปฏิบัติที่ดีของ DDD สนับสนุนการมอบหมายความรับผิดชอบให้แก่หน่วยงานและวัตถุที่มีค่าหากพวกเขาเห็นว่าเหมาะสม ดังนั้นเอนทิตีและวัตถุค่าจะสิ้นสุดลงด้วยตรรกะทางธุรกิจที่ร้ายแรงบางอย่างในนั้น ตอนนี้ถ้าบริการทำงานบนเอนทิตีหรือวัตถุที่มีค่าฉันควรล้อเลียนเอนทิตีหรือวัตถุที่มีค่าและส่งจำลองไปยังบริการ (การเยาะเย้ยจะต้องมีinterfaceสำหรับวัตถุค่าหรือหน่วยงานที่ดูเหมือนจะสนับสนุน) หรือฉันควรnewเป็นเพียงแค่เอนทิตี / ค่าวัตถุและผ่านการใช้งานที่เป็นรูปธรรมไปยังบริการและทำให้เป็นการละเมิดหลักการทดสอบหน่วยของการทดสอบเพียงหนึ่งหน่วย?

3
การนำเสนอเลเยอร์แอปพลิเคชัน VS ใน DDD
ฉันมีปัญหาในการวาดเส้นที่ชัดเจนระหว่าง Presentation และ Application layer ใน Domain Driven Design ไฟล์คอนโทรลเลอร์, มุมมอง, เลย์เอาต์, Javascript และ CSS ควรไปที่ใด มันอยู่ใน Application หรือเลเยอร์การนำเสนอหรือไม่? และถ้าพวกมันรวมกันในเลเยอร์เดียวกันสิ่งที่มีอีกอันหนึ่ง? มันว่างเปล่า

3
DDD และวัตถุค่า Object Value ที่ไม่แน่นอนเป็นตัวเลือกที่ดีสำหรับ Non Aggr เอนทิตีรูทหรือไม่
นี่เป็นปัญหาเล็กน้อย มีเอนทิตีที่มีค่าวัตถุ ไม่ใช่ปัญหา. ฉันแทนที่วัตถุค่าสำหรับวัตถุใหม่จากนั้น nhibernate จะแทรกค่าใหม่และกำพร้าของเก่าแล้วลบทิ้ง ตกลงนั่นเป็นปัญหา ผู้ประกันตนเป็นนิติบุคคลของฉันในโดเมนของฉัน เขามีชุดของที่อยู่ (วัตถุค่า) หนึ่งในที่อยู่คือ MailingAddress เมื่อเราต้องการอัพเดทที่อยู่ทางไปรษณีย์สมมติว่ารหัสไปรษณีย์ผิดตามหลักคำสอนของ Mr. Evans เราต้องแทนที่วัตถุเก่าสำหรับที่อยู่ใหม่เนื่องจากมันไม่เปลี่ยนรูป แต่เราไม่ต้องการลบแถวเจ้าเนื่องจาก PK ของที่อยู่นั้นเป็น FK ในตาราง MailingHistory ดังนั้นตามหลักคำสอนของนายอีแวนส์เรารู้สึกเมามากที่นี่ เว้นแต่ฉันจะทำให้ที่อยู่ของฉันเป็นรายการดังนั้นฉันไม่จำเป็นต้อง "แทนที่" มันและเพียงอัปเดตสมาชิกรหัสไปรษณีย์เช่นวันที่ดีเก่า ๆ คุณจะแนะนำอะไรให้ฉันในกรณีนี้ วิธีที่ฉันเห็นมัน ValueObjects จะมีประโยชน์ก็ต่อเมื่อคุณต้องการสรุปแค็ปซูลกลุ่มของคอลัมน์ของตารางฐานข้อมูล (คอมโพเนนต์ใน nhibernate) ทุกอย่างที่มีรหัสการคงอยู่ในฐานข้อมูลจะดีกว่าถ้าจะให้เป็น Entity (ไม่จำเป็นต้องเป็น root รวม) เพื่อให้คุณสามารถอัปเดตสมาชิกโดยไม่ต้องสร้างกราฟวัตถุทั้งหมดใหม่โดยเฉพาะหากเป็นวัตถุที่ซ้อนกันลึก คุณเห็นด้วยไหม นายอีแวนส์ได้รับอนุญาตให้มีวัตถุค่าที่ไม่แน่นอนหรือไม่? หรือเป็นค่าที่ไม่แน่นอนวัตถุผู้สมัครสำหรับนิติบุคคลหรือไม่ ขอบคุณ

11
ภาพควรจะสามารถปรับขนาดตัวเองใน OOP หรือไม่?
ฉันกำลังเขียนแอพที่จะมีImageเอนทิตีและฉันมีปัญหาในการตัดสินใจว่าควรรับผิดชอบงานใด ก่อนอื่นฉันมีImageชั้นเรียน มันมีเส้นทางความกว้างและคุณลักษณะอื่น ๆ แล้วฉันจะสร้างชั้นสำหรับการดึงภาพด้วยวิธีการเดียวและการทดสอบเช่น:ImageRepositoryfindAllImagesWithoutThumbnail() createThumbnail()แต่ตอนนี้ผมยังจะต้องมีความสามารถในการ ใครควรจัดการกับสิ่งนั้น? ฉันกำลังคิดว่าจะมีImageManagerชั้นเรียนซึ่งจะเป็นชั้นเรียนเฉพาะแอป (จะมีองค์ประกอบที่สามารถนำมาใช้ใหม่ได้อีกด้วยซึ่งเป็นทางเลือกของการจัดการภาพของบุคคลที่สาม หรืออาจจะเป็น 0K เพื่อให้การImageปรับขนาดตัวเอง หรือปล่อยให้ImageRepositoryและImageManagerเป็นชั้นเดียวกันได้หรือไม่ คุณคิดอย่างไร?

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.