การออกแบบโดเมนขับเคลื่อนคืออะไร


200

ใครสักคนช่วยอธิบาย (ในคำศัพท์สั้น ๆ ) ว่าอะไรคือการออกแบบโดเมน ฉันเห็นคำศัพท์ค่อนข้างมาก แต่ไม่เข้าใจว่ามันคืออะไรหรือดูเหมือนอะไร มันแตกต่างจากการออกแบบที่ไม่ใช่โดเมนหรือไม่

นอกจากนี้บางคนสามารถอธิบายว่า Domain Object คืออะไร โดเมนแตกต่างจากวัตถุปกติอย่างไร


6
ความเป็นไปได้ที่ซ้ำกันของการออกแบบโดยใช้โดเมนคืออะไร
Niels van der Rest


สิ่งนี้ตอบคำถามของคุณหรือไม่ Domain Driven Design (DDD) คืออะไร
Satpal

คำตอบ:


113

แก้ไข:

เนื่องจากนี่เป็นผลลัพธ์อันดับต้น ๆ ของ Google และคำตอบของฉันด้านล่างไม่ใช่โปรดอ้างอิงถึงคำตอบที่ดีกว่านี้:

https://stackoverflow.com/a/1222488/1240557

คำตอบเดิม (ยังไม่เสร็จสมบูรณ์ :))

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

จาก: การออกแบบโดเมนขับเคลื่อนโดย Eric Evans

หนังสือเล่มนี้ใช้อธิบาย DDD ได้ค่อนข้างดี

ลงทะเบียนเพื่อดาวน์โหลดบทสรุปของหนังสือหรือดาวน์โหลดสรุปโดยตรง


มินิเวอร์ชั่นนั้นเป็นข้อมูลอ้างอิงที่ยอดเยี่ยมและฉันคิดว่ามันมีประโยชน์แม้ว่าจะมีข้อความฉบับเต็มอยู่ในมือ ฉันมักจะไปก่อนแล้วข้อความเพื่อดูรายละเอียดเพิ่มเติม
Kyri Sarantakos

15
ดังนั้นฉันตอบจาก "อ่านหนังสือเล่มนี้" ซึ่งเป็นไปไม่ได้ที่จะสรุป DDD ในไม่กี่ย่อหน้า? ปรัชญาการออกแบบจะซับซ้อนได้อย่างไร?
Robin Winslow

ฉันจะไม่บอกว่ามันเป็นไปไม่ได้ แต่ฉันคิดว่ามีสถานที่ที่ดีกว่าในการอ่านและหนังสือ Eric Evans เป็นแหล่งข้อมูลที่ดีที่สุดสำหรับหนังสือ imo ดังนั้นทำไมจึงต้องทำซ้ำ
Mikael Östberg

7
ผู้อ่านที่รัก: ถ้าคุณชอบฉันมาที่นี่จากผลการค้นหาอันดับต้น ๆ ของ Google และรู้สึกผิดหวังที่พบคำตอบที่ได้รับการยอมรับอย่างล้นหลาม (ขอโทษ Mikael) ไม่กลัวมีคำอธิบายที่น่าพอใจมากขึ้นที่ SO: stackoverflow.com/a/1222488 / 1240557
kryger

3
ฉันได้อัปเดตคำตอบพร้อมกับลิงก์แล้ว นั่นเป็นคำตอบที่ดีกว่ามาก ขอบคุณ!
Mikael Östberg

42

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

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

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

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

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

การออกแบบที่ขับเคลื่อนด้วยโดเมน: ข้อดีและข้อเสียให้ภาพรวมโดยย่อพร้อมกับความคิดเห็นนี้:

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

ดูบทความนี้การออกแบบโดเมนขับเคลื่อนสำหรับสถาปัตยกรรมบริการซึ่งมีตัวอย่างสั้น ๆ บทความแสดงคำอธิบายรูปขนาดย่อต่อไปนี้ของการออกแบบการขับเคลื่อนโดเมน

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

มาร์ตินฟาวเลอร์ได้เขียนบทความจำนวนหนึ่งซึ่งกล่าวถึงการออกแบบโดเมนที่ขับเคลื่อนด้วยวิธีการ ตัวอย่างเช่นบทความนี้BoundedContextให้ภาพรวมของแนวคิดบริบทที่ถูกผูกไว้จากการพัฒนาไดรฟ์โดเมน

ในวันที่น้อยกว่านี้เราได้รับคำแนะนำให้สร้างแบบรวมของธุรกิจทั้งหมด แต่ DDD ตระหนักดีว่าเราได้เรียนรู้ว่า "การผนวกรวมของแบบจำลองโดเมนสำหรับระบบขนาดใหญ่จะไม่เป็นไปได้หรือคุ้มค่า" [ 1 ] ดังนั้น DDD จึงแบ่งระบบขนาดใหญ่ออกเป็นบริบทที่ถูกผูกไว้ซึ่งแต่ละอันสามารถมีโมเดลแบบรวมเป็นหลักซึ่งเป็นวิธีหนึ่งในการสร้าง MultipleCanonicalModels


21

คุณสามารถเข้าใจการออกแบบโดยใช้โดเมนเป็นครั้งแรกโดยเข้าใจสิ่งต่อไปนี้:

โดเมนคืออะไร

ฟิลด์ที่ระบบถูกสร้าง จัดการสนามบิน, ขายประกัน, ร้านกาแฟ, เที่ยวบินโคจรคุณชื่อมัน

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

แบบจำลองคืออะไร

"การประมาณปัญหาที่เป็นประโยชน์มีประโยชน์" - เจอร์รี่ซัสแมน

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

โดเมนที่ต่างกันอาจสนใจวิธีต่างๆในการสร้างแบบจำลองในสิ่งเดียวกัน ตัวอย่างเช่นแผนกเงินเดือนและฝ่ายทรัพยากรมนุษย์อาจจำลองพนักงานในรูปแบบที่แตกต่างกัน

รูปแบบโดเมนคืออะไร

แบบจำลองสำหรับโดเมน

การออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD) คืออะไร

มันเป็นวิธีการพัฒนาที่ให้ความสำคัญกับรูปแบบโดเมนและเชื่อมต่อกับการใช้งาน DDD ได้รับการประกาศเกียรติคุณและพัฒนาขึ้นครั้งแรกโดย Eric Evans

คัดมาจากที่นี่


12

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

หวังว่าจะช่วย


5

ใน TDD และ BDD คุณ / ทีมจะให้ความสำคัญกับการทดสอบและพฤติกรรมของระบบมากกว่าการติดตั้งโค้ด

วิธีที่คล้ายกันเมื่อนักวิเคราะห์ระบบ, เจ้าของผลิตภัณฑ์, ทีมพัฒนาและ ofcourse โค้ด - เอนทิตี / คลาส, ตัวแปร, ฟังก์ชั่น, กระบวนการส่วนต่อประสานกับผู้ใช้สื่อสารโดยใช้ภาษาเดียวกันซึ่งเรียกว่า Domain Driven Design

DDD เป็นกระบวนการคิด เมื่อสร้างแบบจำลองการออกแบบซอฟต์แวร์ที่คุณต้องการให้โดเมนธุรกิจ / กระบวนการในศูนย์ความสนใจมากกว่าโครงสร้างข้อมูลกระแสข้อมูลเทคโนโลยีการพึ่งพาภายในและภายนอก

มีหลายวิธีในการสร้างแบบจำลอง systerm โดยใช้ DDD

  • การจัดหากิจกรรม (ใช้เหตุการณ์เป็นแหล่งความจริงเดียว)
  • ฐานข้อมูลเชิงสัมพันธ์
  • ฐานข้อมูลกราฟ
  • ใช้ภาษาทำงาน

วัตถุโดเมน:

ในคำพูดที่ไร้เดียงสาซึ่งเป็นวัตถุที่

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

TDD - การพัฒนาแบบทดสอบขับเคลื่อน
Nitin babariya

BDD - การพัฒนาพฤติกรรมขับเคลื่อน
Nitin babariya

DDD - การพัฒนาโดเมนขับเคลื่อน
Nitin babariya

DDD -> การออกแบบโดเมนขับเคลื่อน~ การพัฒนา ~
psaxton

4

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

  • ในโครงการขนาดใหญ่ที่มีข้อกำหนดที่ซับซ้อนจะไม่มีประโยชน์แม้ว่าจะเป็นวิธีการออกแบบที่ยอดเยี่ยมสำหรับโครงการขนาดเล็ก

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

ดังนั้น DDD จึงจัดการปัญหาแรกด้วยการพิจารณาโครงการหลักเป็น Domain และแยกส่วนของโครงการนี้เป็นชิ้นเล็ก ๆ ซึ่งเรามีชื่อเสียงในบริบทของ Bounded และแต่ละส่วนไม่มีอิทธิพลต่อชิ้นอื่น ๆ และปัญหาที่สองได้รับการแก้ไขด้วยภาษาที่แพร่หลายซึ่งเป็นภาษาทั่วไประหว่างสมาชิกในทีมเทคนิคและเจ้าของผลิตภัณฑ์ที่ไม่ใช่ด้านเทคนิค แต่มีความรู้เพียงพอเกี่ยวกับความต้องการของพวกเขา

โดยทั่วไปคำจำกัดความง่ายๆสำหรับDomainเป็นโครงการหลักที่สร้างรายได้ให้กับเจ้าของและทีมอื่น ๆ


1

ฉันเชื่อว่าไฟล์ PDF ต่อไปนี้จะให้ภาพที่ใหญ่ขึ้น การออกแบบขับเคลื่อนด้วยโดเมนโดย Eric Evans

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


0

ฉันไม่ต้องการที่จะทำซ้ำคำตอบของผู้อื่นดังนั้นในระยะสั้นฉันอธิบายบางความเข้าใจผิดที่พบบ่อย

  • ทรัพยากรที่ใช้งานได้: รูปแบบหลักการและการปฏิบัติของการออกแบบไดรฟ์ในโดเมนโดย Scott Millett
  • มันเป็นวิธีการสำหรับระบบธุรกิจที่ซับซ้อน ต้องใช้ทุกเรื่องทางเทคนิคเมื่อสื่อสารกับผู้เชี่ยวชาญทางธุรกิจ
  • มันให้ความเข้าใจอย่างกว้างขวางเกี่ยวกับธุรกิจ (ง่ายและกลั่นรุ่น) ของธุรกิจข้ามทีมทั้งหมด
  • มันทำให้รูปแบบธุรกิจที่สอดคล้องกับรูปแบบรหัสโดยใช้ภาษาที่แพร่หลาย (ภาษาที่เข้าใจโดยทีม dev ทั้งหมดผู้เชี่ยวชาญด้านธุรกิจนักวิเคราะห์ธุรกิจ, ... ) ซึ่งใช้สำหรับการสื่อสารภายในทีม dev หรือ dev กับทีมอื่น ๆ
  • มันมีอะไรจะทำอย่างไรกับการบริหารจัดการโครงการ แม้ว่าจะสามารถนำมาใช้อย่างสมบูรณ์แบบในวิธีการจัดการโครงการเช่น Agile
  • คุณควรหลีกเลี่ยงการใช้ทุกอย่างในโครงการของคุณ

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

    โดยทั่วไปเป็นเพราะใช้เวลาและความพยายามมากเกินไป ดังนั้นจึงแนะนำให้แบ่งโดเมนทั้งหมดเป็นโดเมนย่อยและใช้กับโดเมนที่มีมูลค่าทางธุรกิจสูง (เช่นไม่ได้อยู่ในโดเมนย่อยทั่วไปเช่นอีเมล, ... )

  • มันไม่ใช่การเขียนโปรแกรมเชิงวัตถุ ส่วนใหญ่เป็นวิธีการแก้ปัญหาและ ( บางครั้ง ) คุณไม่จำเป็นต้องใช้รูปแบบ OO (เช่น Gang of Four) ในโมเดลโดเมนของคุณ เพียงเพราะผู้เชี่ยวชาญธุรกิจไม่สามารถเข้าใจได้ (พวกเขาไม่ทราบมากเกี่ยวกับโรงงานมัณฑนากร ... ) แม้จะมีรูปแบบบางอย่างใน DDD (เช่น Transaction Script, Table Module) ซึ่งไม่สอดคล้องกับแนวคิด OO 100%

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