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

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

11
รูปแบบ DAO และ Repository แตกต่างกันอย่างไร
อะไรคือความแตกต่างระหว่าง Data Access Objects (DAO) และรูปแบบ Repository ฉันกำลังพัฒนาแอปพลิเคชันที่ใช้ Enterprise Java Beans (EJB3), Hibernate ORM เป็นโครงสร้างพื้นฐานและ Domain-Driven Design (DDD) และ Test-Driven Development (TDD) เป็นเทคนิคการออกแบบ

7
ฉันจะหาตัวอย่างที่ดีสำหรับ DDD ได้จากที่ใด [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา ฉันเรียนรู้เกี่ยวกับการออกแบบการขับเคลื่อนด้วยโดเมน แต่มีปัญหาในทางปฏิบัติบางอย่างที่ทำให้ฉันสับสนซึ่งฉันคิดว่าการเห็นตัวอย่างที่ดีบางอย่างอาจชัดเจนขึ้น มีใครรู้บ้างเกี่ยวกับตัวอย่างโค้ดที่ใช้งานได้ดีซึ่งทำหน้าที่ได้ดีในการสร้างแบบจำลองแนวคิด DDD พื้นฐานหรือไม่? สนใจเป็นพิเศษค่ะ รูปแบบโดเมนตัวอย่าง คลัง การใช้บริการ Domain / Application วัตถุค่า รากรวม

2
Domain Driven Design (DDD) คืออะไร [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา ปรับปรุงคำถามนี้ ฉันเห็น DDD (การออกแบบการขับเคลื่อนด้วยโดเมน) ถูกใช้บ่อยๆในบทความ - ฉันได้อ่านรายการ Wikipedia เกี่ยวกับ DDD แต่ยังไม่สามารถเข้าใจได้ว่ามันคืออะไรจริง ๆ และฉันจะนำไปใช้ในการสร้างเว็บไซต์ของฉันได้อย่างไร

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

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

12
DDD - กฎที่เอนทิตีไม่สามารถเข้าถึงที่เก็บโดยตรง
ในการขับเคลื่อนโดเมนออกแบบดูเหมือนว่าจะมีจำนวนมากของข้อตกลงที่หน่วยงานที่เก็บไม่ควรเข้าถึงโดยตรง สิ่งนี้มาจากหนังสือของ Eric Evans Domain Driven Designหรือมาจากที่อื่นหรือไม่ มีคำอธิบายที่ดีสำหรับเหตุผลอยู่เบื้องหลังที่ไหน? แก้ไข: เพื่อชี้แจง: ฉันไม่ได้พูดถึงวิธีปฏิบัติแบบ OO แบบคลาสสิกของการแยกการเข้าถึงข้อมูลออกเป็นเลเยอร์แยกต่างหากจากตรรกะทางธุรกิจ - ฉันกำลังพูดถึงการจัดเรียงเฉพาะโดยที่ DDD หน่วยงานไม่ควรพูดคุยกับข้อมูล access layer เลย (เช่นพวกเขาไม่ควรจะเก็บการอ้างอิงไปยังวัตถุ Repository) อัปเดต: ฉันให้รางวัลแก่ BacceSR เพราะคำตอบของเขาดูใกล้เคียงที่สุด แต่ฉันก็ยังค่อนข้างมืดอยู่กับเรื่องนี้ หากเป็นหลักการสำคัญเช่นนั้นควรมีบทความดีๆเกี่ยวกับเรื่องนี้ออนไลน์ที่ไหนสักแห่งใช่ไหม? อัปเดต: มีนาคม 2556 จำนวนผู้โหวตในคำถามบ่งบอกว่ามีความสนใจในเรื่องนี้มากมายและถึงแม้ว่าจะมีคำตอบมากมาย แต่ฉันก็ยังคิดว่าจะมีช่องว่างมากขึ้นถ้าผู้คนมีความคิดเกี่ยวกับเรื่องนี้

9
บริการควรส่งคืน DTO เสมอหรือพวกเขาสามารถส่งคืนโมเดลโดเมนได้หรือไม่
ฉันกำลังออกแบบแอพพลิเคชั่นขนาดใหญ่อีกครั้งเราใช้สถาปัตยกรรมหลายชั้นที่ใช้ DDD เรามี MVC พร้อมชั้นข้อมูล (การใช้พื้นที่เก็บข้อมูล) ชั้นโดเมน (คำจำกัดความของรูปแบบโดเมนและอินเทอร์เฟซ - พื้นที่เก็บข้อมูลบริการหน่วยงาน) ชั้นบริการ (การนำบริการไปใช้) จนถึงตอนนี้เราใช้โมเดลโดเมน (เอนทิตีส่วนใหญ่) ครอบคลุมเลเยอร์ทั้งหมดและเราใช้ DTOs เป็นแบบจำลองการดูเท่านั้น (ในตัวควบคุมบริการส่งคืนโมเดลโดเมนและตัวควบคุมสร้างโมเดลการดูซึ่งส่งผ่านไปยังมุมมอง) ฉันได้อ่านบทความมากมายเกี่ยวกับการใช้ไม่ใช้การแมปและการผ่าน DTO ฉันเข้าใจว่าไม่มีคำตอบที่ชัดเจน แต่ฉันไม่แน่ใจว่ามันใช้ได้หรือไม่ส่งคืนโมเดลโดเมนจากบริการไปยังตัวควบคุม ถ้าฉันส่งคืนโมเดลโดเมนมันยังไม่เคยผ่านไปยังมุมมองเนื่องจากตัวควบคุมจะสร้างมุมมองเฉพาะมุมมองเสมอ - ในกรณีนี้มันดูเป็นเรื่องถูกกฎหมาย ในทางกลับกันมันไม่รู้สึกว่าถูกต้องเมื่อโมเดลโดเมนออกจากชั้นธุรกิจ (ชั้นบริการ) บางครั้งบริการจำเป็นต้องส่งคืนวัตถุข้อมูลที่ไม่ได้กำหนดไว้ในโดเมนและจากนั้นเราต้องเพิ่มวัตถุใหม่ไปยังโดเมนที่ไม่ได้ถูกแมปหรือสร้างวัตถุ POCO (นี่น่าเกลียดเนื่องจากบริการบางอย่างกลับโดเมนบางรุ่น ส่งคืน DTO อย่างมีประสิทธิภาพ) คำถามคือ - ถ้าเราใช้โมเดลการดูอย่างเคร่งครัดเป็นไรหรือไม่ที่จะส่งคืนโมเดลโดเมนไปยังตัวควบคุมหรือเราควรใช้ DTOs สำหรับการสื่อสารกับชั้นบริการเสมอหรือไม่ ถ้าเป็นเช่นนั้นจะเป็นการดีที่จะปรับรูปแบบโดเมนตามบริการที่ต้องการ (ตรงไปตรงมาฉันไม่คิดอย่างนั้นเพราะบริการควรใช้โดเมนใด) หากเราควรยึดติดกับ DTO อย่างเคร่งครัดควรกำหนดไว้ในเลเยอร์บริการหรือไม่ (ฉันคิดอย่างนั้น) บางครั้งก็ชัดเจนว่าเราควรใช้ DTOs (เช่นเมื่อบริการดำเนินการตรรกะทางธุรกิจจำนวนมากและสร้างวัตถุใหม่) บางครั้งก็ชัดเจนว่าเราควรใช้เพียงแค่รูปแบบโดเมน (เช่นเมื่อบริการสมาชิกส่งคืนผู้ใช้โลหิตจาง s) …

8
DTO = ViewModel?
ฉันใช้ NHibernate เพื่อคงวัตถุโดเมนของฉัน เพื่อให้สิ่งต่างๆง่ายขึ้นฉันใช้โครงการ ASP.NET MVC เป็นทั้งเลเยอร์การนำเสนอและเลเยอร์บริการของฉัน ฉันต้องการส่งคืนอ็อบเจ็กต์โดเมนของฉันใน XML จากคลาสคอนโทรลเลอร์ของฉัน หลังจากอ่านโพสต์บางส่วนที่นี่ใน Stack Overflow ฉันรวบรวม DTO เป็นวิธีที่จะไป อย่างไรก็ตามฉันยังเจอโพสต์ที่พูดถึง ViewModel คำถามของฉัน: Data Transfer Objects และ ViewModels เป็นสิ่งเดียวกันหรือไม่ หรือ ViewModel เป็นรูปแบบย่อยของ DTO หรือไม่?

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

4
จะแมป View Model กลับไปยัง Domain Model ในการดำเนินการ POST ได้อย่างไร?
ทุกบทความที่พบในอินเทอร์เน็ตเกี่ยวกับการใช้ ViewModels และการใช้ Automapper จะให้แนวทางของการทำแผนที่ทิศทาง "Controller -> View" คุณนำโมเดลโดเมนพร้อมกับ Select Lists ทั้งหมดไปไว้ใน ViewModel แบบพิเศษและส่งไปยังมุมมอง ชัดเจนและดี มุมมองมีรูปแบบและในที่สุดเราก็อยู่ในการดำเนินการ POST ที่นี่ Model Binders ทั้งหมดจะเข้ามาในฉากพร้อมกับ[เห็นได้ชัด] View Model อื่นซึ่ง[อย่างเห็นได้ชัด] เกี่ยวข้องกับ ViewModel ดั้งเดิมอย่างน้อยก็ในส่วนของรูปแบบการตั้งชื่อเพื่อประโยชน์ในการเชื่อมโยงและการตรวจสอบความถูกต้อง คุณจับคู่กับโมเดลโดเมนของคุณได้อย่างไร? ปล่อยให้มันเป็นการกระทำแทรกเราสามารถใช้ Automapper เดียวกัน แต่ถ้าเป็นการดำเนินการอัปเดตล่ะ? เราต้องดึงข้อมูลเอนทิตีโดเมนของเราจากที่เก็บอัปเดตคุณสมบัติตามค่าใน ViewModel และบันทึกลงใน Repository ภาคผนวก 1 (9 กุมภาพันธ์ 2553):บางครั้งการกำหนดคุณสมบัติของโมเดลไม่เพียงพอ ควรมีการดำเนินการบางอย่างกับ Domain Model ตามค่าของ View Model กล่าวคือควรเรียกวิธีการบางอย่างบน Domain Model …

14
เหตุใดฉันจึงควรแยกเอนทิตีโดเมนของฉันออกจากเลเยอร์การนำเสนอของฉัน
ส่วนหนึ่งของการออกแบบที่ขับเคลื่อนด้วยโดเมนซึ่งดูเหมือนจะไม่มีรายละเอียดมากนักนั่นคือวิธีและเหตุผลที่คุณควรแยกโมเดลโดเมนของคุณออกจากอินเทอร์เฟซของคุณ ฉันพยายามโน้มน้าวเพื่อนร่วมงานว่านี่เป็นแนวทางปฏิบัติที่ดี แต่ดูเหมือนฉันจะไม่ค่อยก้าวหน้าสักเท่าไหร่ ... พวกเขาใช้เอนทิตีโดเมนทุกที่ที่พวกเขาต้องการในการนำเสนอและเลเยอร์อินเทอร์เฟซ เมื่อฉันโต้แย้งกับพวกเขาว่าพวกเขาควรใช้โมเดลการแสดงผลหรือ DTO เพื่อป้องกันเลเยอร์โดเมนจากเลเยอร์อินเทอร์เฟซพวกเขาตอบโต้ว่าพวกเขาไม่เห็นคุณค่าทางธุรกิจในการทำอะไรแบบนั้นเพราะตอนนี้คุณมีวัตถุ UI ที่ต้องดูแล เช่นเดียวกับวัตถุโดเมนดั้งเดิม ดังนั้นฉันกำลังมองหาเหตุผลที่เป็นรูปธรรมบางอย่างที่สามารถใช้เพื่อสำรองข้อมูลนี้ได้ โดยเฉพาะ: เหตุใดเราจึงไม่ควรใช้วัตถุโดเมนในเลเยอร์การนำเสนอของเรา (หากคำตอบคือคำตอบที่ชัดเจน "การแยกส่วน" โปรดอธิบายว่าเหตุใดจึงมีความสำคัญในบริบทนี้) เราควรใช้ออบเจ็กต์หรือโครงสร้างเพิ่มเติมเพื่อแยกออบเจ็กต์โดเมนของเราออกจากอินเทอร์เฟซหรือไม่?

3
รหัสที่พิมพ์อย่างมากใน Core Framework เอนทิตี
ฉันพยายามที่จะมีIdคลาสที่พิมพ์ออกมาอย่างรุนแรงซึ่งตอนนี้ถือภายใน 'ยาว' ภายใน การใช้งานด้านล่าง ปัญหาที่ฉันมีการใช้สิ่งนี้ในเอนทิตีของฉันคือEntity Frameworkให้ฉันข้อความว่ารหัสทรัพย์สินถูกแมปไปแล้ว ดูIEntityTypeConfigurationด้านล่างของฉัน หมายเหตุ:ฉันไม่ได้มีจุดประสงค์ที่จะใช้งาน DDD อย่างเข้มงวด ดังนั้นโปรดเก็บไว้ในใจเมื่อแสดงความคิดเห็นหรือตอบ รหัสทั้งหมดที่อยู่ด้านหลังพิมพ์Idสำหรับนักพัฒนาที่มาถึงโครงการที่พวกเขาพิมพ์อย่างยิ่งที่จะใช้รหัสในเอนทิตีทั้งหมดของพวกเขาแน่นอนแปลเป็นlong(หรือBIGINT) - แต่มันชัดเจนสำหรับคนอื่น ๆ ใต้คลาสและการกำหนดค่าซึ่งไม่ทำงาน ซื้อคืนภาคสามารถพบได้ที่https://github.com/KodeFoxx/Kf.CleanArchitectureTemplate.NetCore31 , Idระดับที่ (แสดงความคิดเห็นตอนนี้): https://github.com/KodeFoxx/Kf.CleanArchitectureTemplate.NetCore31/blob/master/Source/Common/Kf.CANetCore31/DomainDrivenDesign/Id.cs EntityและValueObjectคลาส (โดยที่EntityคุณสมบัติIdเป็นประเภทId. cs (ด้านบน): https://github.com/KodeFoxx/Kf.CleanArchitectureTemplate.NetCore31/tree/master/Source/Common/Kf.CANetCore31/DomainDrivenDesign การกำหนดค่าที่: https://github.com/KodeFoxx/Kf.CleanArchitectureTemplate.NetCore31/tree/master/Source/Infrastructure/Persistence/Kf.CANetCore31.Infrastructure.Persistence.Ef/EntityTypeConfigurations Idการใช้งานในชั้นเรียน (ทำเครื่องหมายล้าสมัยในขณะนี้เพราะฉันละทิ้งความคิดจนกว่าฉันจะพบทางออกสำหรับเรื่องนี้ namespace Kf.CANetCore31.DomainDrivenDesign { [DebuggerDisplay("{DebuggerDisplayString,nq}")] [Obsolete] public sealed class Id : ValueObject { public static implicit operator Id(long value) => new …

3
การแมปเอนทิตีเดียวกันกับตารางที่แตกต่างกัน
ความรู้เกี่ยวกับโดเมน ฉันกำลังเขียนซอฟต์แวร์ POS (จุดขาย) ที่อนุญาตให้ชำระค่าสินค้าหรือคืนเงินได้ เมื่อชำระเงินหรือคืนเงินหนึ่งต้องระบุการโอนเงินที่หมายถึงการใช้: เงินสด EFT (~ = บัตรเครดิต) บัตรสะสมคะแนนบัตรกำนัล ฯลฯ การโอนเงินหมายถึงชุดค่าที่แน่นอนและเป็นที่รู้จัก (ชนิดของ enum) ส่วนที่ยุ่งยากคือฉันต้องสามารถจัดเก็บชุดย่อยที่กำหนดเองของวิธีการเหล่านี้สำหรับการชำระเงินและการคืนเงิน (ทั้งสองชุดอาจแตกต่างกัน) ในเครื่อง POS ตัวอย่างเช่น: วิธีการชำระเงินที่พร้อมให้บริการ: เงินสด, EFT, การ์ดความภักดี, คูปอง การคืนเงินที่มีอยู่หมายถึง: เงินสดบัตรกำนัล สถานะปัจจุบันของการดำเนินงาน ฉันเลือกที่จะใช้แนวคิดการโอนเงินหมายถึง: public abstract class MoneyTransferMean : AggregateRoot { public static readonly MoneyTransferMean Cash = new CashMoneyTransferMean(); public static readonly MoneyTransferMean EFT …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.