การสร้างใหม่ในการออกแบบโดเมนขับเคลื่อน [ปิด]


10

ฉันเพิ่งเริ่มทำงานในโครงการและเรากำลังใช้การออกแบบที่ขับเคลื่อนด้วยโดเมน (ตามที่กำหนดโดย Eric Evans ในการออกแบบที่ขับเคลื่อนด้วยโดเมน: การแก้ปัญหาความซับซ้อนในหัวใจของซอฟต์แวร์ฉันเชื่อว่าโครงการของเราเป็นผู้สมัครสำหรับการออกแบบนี้ แบบที่อีแวนส์อธิบายไว้ในหนังสือของเขา

ฉันกำลังดิ้นรนกับความคิดในการปรับโครงสร้างใหม่อย่างต่อเนื่อง

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

เป็นวิธีที่มีประสิทธิภาพในการโน้มน้าวตัวเอง (และอื่น ๆ ) คุณควร refactor หลังจากที่คุณได้รับรูปแบบโดเมนที่ชัดเจนคืออะไร? ท้ายที่สุดการปรับโครงสร้างองค์กรเพื่อปรับปรุงโค้ดหรือประสิทธิภาพอาจแตกต่างอย่างสิ้นเชิงจากวิธีการแสดงออกในแง่ของรหัสภาษาที่แพร่หลาย บางครั้งดูเหมือนว่าไม่มีเวลาพอที่จะสร้างใหม่

โชคดีที่ SCRUM ปล่อยให้ตนเองฟื้นฟู ลักษณะซ้ำของ SCRUM ทำให้ง่ายต่อการสร้างชิ้นเล็ก ๆ และเปลี่ยนแปลงและมัน แต่เมื่อเวลาผ่านไปชิ้นส่วนนั้นจะใหญ่ขึ้นและจะเกิดอะไรขึ้นถ้าคุณมีความก้าวหน้าหลังจากชิ้นส่วนนั้นใหญ่มากจนยากที่จะเปลี่ยน

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

ขอบคุณ!


หากคุณกำลังเขียนโค้ดที่คุณไม่คิดว่าคุณจะสามารถเปลี่ยนแปลงได้โดยไม่คำนึงถึงขนาดให้หยุด
JeffO

@Jeff: มันไม่ได้เป็นเรื่องของการไม่สามารถเปลี่ยนมันเป็นเรื่องของเวลาและทรัพยากรที่จำเป็นสำหรับการเปลี่ยนมันเพิ่มขึ้นเมื่อได้รับรหัสเพิ่ม
Andrew Whitaker

2
หากคุณกำลังเพิ่มรหัสการรู้ว่ารหัสที่มีอยู่นั้นจำเป็นต้องมีการรีแฟคเตอร์ใหม่ แต่ไม่เป็นเช่นนั้นคุณกำลังเสี่ยง ไม่ได้หมายความว่ามันจะไม่ทำงาน
JeffO

คำตอบ:


9

ฉันเป็นแฟนตัวยงของ DDD มาระยะหนึ่งแล้ว (ทั้งที่มีและไม่มีเครือข่ายความปลอดภัยของกรอบการทดสอบ)

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

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


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

การสร้างใหม่เป็นคุณลักษณะหนึ่งที่ฉันจะจดจำได้
Filip Dupanović

5

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

ในกรณีที่เราเพิ่งทำงานเกี่ยวกับการประยุกต์ใช้ความซับซ้อนของโดเมนที่เหมาะสม มันเป็นระบบการเรียกเก็บเงิน / สัญญาและเราได้แนะนำอัตราใหม่ เราใช้กระบวนการที่คล่องตัว 2 สัปดาห์ในการแก้ไขปัญหาอย่างแม่นยำ

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

เพื่อตัดเรื่องให้สั้นลงเราสามารถรับ 90% ของเรื่องราวที่ทำด้วยแบบจำลองที่ไม่ถูกต้อง แต่เราได้มาถึงจุดที่ในทุกส่วนของรหัสที่เราใช้ห่ออัตราใหม่เป็นเก่าและ / หรือ สร้างถ้า newRate อื่น ๆ oldRate ทุกที่ เราต่อสู้กับกำแพงอิฐที่เป็นที่เลื่องลือ เราครึ่งทางผ่านส่วนนี้ของโครงการและรู้ว่าเวลาที่จะเสร็จสมบูรณ์จะชี้แจงหรือไม่ทำงานกับรูปแบบโดเมนที่ไม่ถูกต้อง ดังนั้นเราจึงทำให้สัญลักษณ์แสดงหัวข้อย่อยแบ่งเรื่องออกเป็นแปดเรื่องและสร้างตัวแบบ Domain

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

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


คำตอบที่ดี เราผ่านบางสิ่งที่คล้ายคลึงกับสิ่งนี้ทุกสองสามเดือน ดีใจที่รู้ว่าเราไม่ได้อยู่คนเดียว!
Andrew Whitaker

3

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

สิ่งที่เกิดขึ้นนี้คือผู้คนเคยทำตัวแบบในแบบที่มันไม่ได้มีไว้เพื่อและทำลายส่วนอื่น ๆ ของแบบจำลองเพื่อพยายาม "ทำให้มันใช้งานได้"

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


3

สำหรับบางส่วนของรหัสการทำซ้ำอย่างต่อเนื่องจะมากเกินไป สำหรับส่วนอื่น ๆ ของรหัส (ใน DDD ที่เรียกว่าCore Domain ) เป็นสิ่งจำเป็น การทำความเข้าใจว่ารหัสไม่ใช่วิธีที่ควรเพิ่มการรับรู้พิเศษให้กับนักพัฒนา (ความแตกต่างระหว่างความเข้าใจของเราเกี่ยวกับโดเมนและการใช้งานในปัจจุบัน) ที่จะทำให้การวิวัฒนาการเพิ่มเติมยากขึ้นและ / หรือมีราคาแพง

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

แต่ที่ว่าจะมีราคาแพงเมื่อนำไปใช้ทุกรหัสโปรแกรม พื้นที่ที่ไม่สำคัญสำหรับธุรกิจ (การสนับสนุนหรือโดเมนย่อยทั่วไปใน DDD lingo) อาจต้องใช้วิธีการที่ซับซ้อนน้อยกว่าที่สงวนไว้สำหรับแกนหลัก

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