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

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

38 functional-programming  domain-driven-design 

ฉันกำลังทำงานในโครงการที่เราพยายามใช้ทั้งการออกแบบที่ขับเคลื่อนด้วยโดเมนและ REST กับสถาปัตยกรรมที่มุ่งเน้นบริการ เราไม่กังวลเกี่ยวกับการปฏิบัติตาม REST 100% อาจเป็นการดีกว่าถ้าจะบอกว่าเรากำลังพยายามสร้าง HTTP API ที่เน้นการใช้ทรัพยากร (~ ระดับ 2ของแบบจำลองวุฒิภาวะ REST ของ Richardson) แต่เรากำลังพยายามที่จะอยู่ห่างจากการใช้ RPC-รูปแบบของการร้องขอ HTTP เช่นเราพยายามที่จะดำเนินการของเรา HTTP กริยาตามRFC2616มากกว่าที่จะใช้POSTในการทำIsPostalAddressValid(...)เช่น อย่างไรก็ตามการเน้นเรื่องนี้ดูเหมือนว่าจะเป็นค่าใช้จ่ายของความพยายามของเราที่จะใช้การออกแบบที่ขับเคลื่อนด้วยโดเมน มีเพียงGET, POST, PUT, DELETEและไม่กี่วิธีที่ไม่ค่อยได้ใช้อื่น ๆ ที่เรามีแนวโน้มที่จะสร้างบริการ cruddy และบริการ cruddy มีแนวโน้มที่จะมีรูปแบบโดเมนโรคโลหิตจาง POST: รับข้อมูลตรวจสอบความถูกต้องถ่ายโอนข้อมูลไปยังข้อมูล GET: ดึงข้อมูลกลับคืนมา ไม่มีตรรกะทางธุรกิจที่แท้จริงที่นั่น นอกจากนี้เรายังใช้ข้อความ (เหตุการณ์) ระหว่างบริการและดูเหมือนว่าตรรกะทางธุรกิจส่วนใหญ่จะสร้างขึ้นมา REST และ DDD มีความตึงเครียดในบางระดับหรือไม่? (หรือฉันเข้าใจผิดบางอย่างที่นี่เราอาจทำผิดอย่างอื่นหรือไม่) เป็นไปได้ไหมที่จะสร้างโมเดลโดเมนที่แข็งแกร่งในสถาปัตยกรรมเชิงบริการขณะที่หลีกเลี่ยงการโทร HTTP สไตล์ RPC?

34 rest  domain-driven-design  domain-model 

ฉันเพิ่งอ่านบทความนี้และฉันสับสน ลองจินตนาการ 1 webapp และ 1 แอพลิเคชันที่แตกต่างกันทำหน้าที่เป็น "คนงาน" ทั้งสองร่วมกันฐานข้อมูลเดียวกัน โอ้ฉันพูดว่า "การแบ่งปัน" .. แต่บทความจะเตือนอะไร : ประการที่สี่การแบ่งปันฐานข้อมูลระหว่างแอปพลิเคชัน (หรือบริการ) เป็นสิ่งที่ไม่ดี มันเป็นการล่อลวงเกินไปที่จะทำให้รัฐร่วมอสัณฐานอยู่ในนั้นและก่อนที่คุณจะรู้ว่าคุณจะมีสัตว์ประหลาดคู่ขนานอย่างมหาศาล => ไม่เห็นด้วย มีบางกรณีที่แอปพลิเคชันที่แตกต่างยังคงเป็นส่วนหนึ่งของหน่วยเดียวกันดังนั้นแนวคิดของ "ปัญหาการมีเพศสัมพันธ์" จึงไม่มีเหตุผลในกรณีนี้ มาดำเนินการต่อ: เว็บแอปจัดการคำขอ HTTP ของไคลเอ็นต์และอาจอัปเดตเมื่อใดก็ได้ที่มีการรวม (คำศัพท์ DDD) เพื่อสร้างกิจกรรมโดเมนที่สอดคล้องกัน เป้าหมายของผู้ปฏิบัติงานคือการจัดการกิจกรรมโดเมนเหล่านั้นโดยการประมวลผลงานที่ต้องการ ประเด็นก็คือ: ข้อมูลเหตุการณ์ควรส่งผ่านไปยังผู้ปฏิบัติงานอย่างไร วิธีแรกในการส่งเสริมการอ่านบทความคือการใช้ RabbitMQ เป็นมิดเดิลแวร์ที่มุ่งเน้นข้อความ เวิร์กโฟลว์จะง่าย: เมื่อใดก็ตามที่เว็บไดโนสร้างเหตุการณ์มันจะเผยแพร่ผ่าน RabbitMQ ซึ่งฟีดคนงาน ข้อเสียเปรียบก็คือไม่มีสิ่งใดรับประกันความสอดคล้องทันทีระหว่างการคอมมิชชันของการอัพเดตแบบรวมและการเผยแพร่เหตุการณ์โดยไม่ต้องจัดการกับความล้มเหลวในการส่งที่เป็นไปได้ ... หรือปัญหาฮาร์ดแวร์; นั่นเป็นอีกประเด็นหลัก ตัวอย่าง: เป็นไปได้ว่าเหตุการณ์ถูกเผยแพร่โดยไม่ประสบความสำเร็จในการอัปเดตรวม ... ส่งผลให้เกิดเหตุการณ์ที่แสดงถึงการแสดงโมเดลโดเมนที่ผิดพลาด คุณสามารถยืนยันได้ว่า XA …

33 architecture  domain-driven-design  message-queue  middleware 

โดยทั่วไปฉันใช้รหัสการเพิ่มอัตโนมัติเป็นคีย์หลักในฐานข้อมูล ฉันพยายามเรียนรู้ประโยชน์ของการใช้ GUID ฉันได้อ่านบทความนี้: https://betterexplained.com/articles/the-quick-guide-to-guids/ ฉันรู้ว่า GUID เหล่านี้ใช้เพื่อระบุวัตถุในระดับแอปพลิเคชัน พวกเขายังเก็บไว้เป็นคีย์หลักในระดับฐานข้อมูล ตัวอย่างเช่นสมมติว่าฉันมีคลาสต่อไปนี้: public class Person { public GUID ID; public string Name; .. //Person Methods follow } ว่าฉันต้องการสร้างคนใหม่ในหน่วยความจำแล้วใส่คนลงในฐานข้อมูล ฉันขอทำสิ่งนี้ได้ไหม Person p1 = new Person(); p1.ID=GUID.NewGUID(); PersonRepository.Insert(p1); สมมติว่าฉันมีฐานข้อมูลที่ประกอบด้วยแถวนับล้านแถวที่มี GUID เป็นคีย์หลัก สิ่งนี้จะไม่ซ้ำกันหรือไม่ ฉันเข้าใจแม้แต่ GUID อย่างถูกต้องหรือไม่ ผมอ่านบทความนี้ก่อนหน้านี้: http://enterprisecraftsmanship.com/2014/11/15/cqs-with-database-generated-ids/ มันทำให้ฉันสับสนเล็กน้อยตามที่ปรากฏเพื่อแนะนำสื่อกลางที่มีความสุขระหว่าง GUID และจำนวนเต็มเป็นคีย์หลัก แก้ไข 11/06/18 ฉันเชื่อว่า Guids …

32 c#  domain-driven-design  sql-server 

ฉันกำลังศึกษา DDD ในวันนี้และฉันมีคำถามบางอย่างเกี่ยวกับวิธีจัดการที่เก็บด้วย DDD อันที่จริงฉันได้พบกับสอง possibilies: คนแรก วิธีแรกในการจัดการบริการที่ฉันอ่านคือการฉีดที่เก็บและรูปแบบโดเมนในบริการแอปพลิเคชัน ด้วยวิธีนี้หนึ่งในวิธีการบริการแอปพลิเคชันเราเรียกวิธีการบริการโดเมน (การตรวจสอบกฎธุรกิจ) และถ้าเงื่อนไขเป็นสิ่งที่ดีพื้นที่เก็บข้อมูลจะถูกเรียกในวิธีพิเศษเพื่อยืนยัน / ดึงเอนทิตีจากฐานข้อมูล วิธีง่ายๆในการทำสิ่งนี้อาจเป็น: class ApplicationService{ constructor(domainService, repository){ this.domainService = domainService this.repository = repository } postAction(data){ if(this.domainService.validateRules(data)){ this.repository.persist(new Entity(data.name, data.surname)) } // ... } } อันที่สอง ความเป็นไปได้ที่สองคือการฉีดที่เก็บภายใน domainService แทนและเพื่อใช้ที่เก็บผ่านบริการโดเมนเท่านั้น: class ApplicationService{ constructor(domainService){ this.domainService = domainService } postAction(data){ if(this.domainService.persist(data)){ console.log('all is …

29 design  domain-driven-design 

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

29 design  design-patterns  architecture  domain-driven-design  entity-framework 

โปรดดูรหัสด้านล่าง; มันทดสอบเพื่อดูว่าบุคคลที่มีเพศหญิงมีสิทธิ์ได้รับข้อเสนอ 1: [Fact] public void ReturnsFalseWhenGivenAPersonWithAGenderOfFemale() { var personId = Guid.NewGuid(); var gender = "F"; var person = new Person(personId, gender); var id = Guid.NewGuid(); var offer1 = new Offer1(id,"Offer1"); Assert.False(offer1.IsEligible(person)); } การทดสอบหน่วยนี้สำเร็จ อย่างไรก็ตามจะล้มเหลวหากมีการเสนอ 'Offer1' ให้กับสตรีในอนาคต เป็นที่ยอมรับหรือไม่ - ถ้าตรรกะทางธุรกิจโดยรอบเสนอ 1 การเปลี่ยนแปลงการทดสอบหน่วยจะต้องเปลี่ยน โปรดทราบว่าในบางกรณี (สำหรับข้อเสนอบางอย่าง) ตรรกะทางธุรกิจจะเปลี่ยนไปในฐานข้อมูลเช่นนี้: update Offers set Gender='M' where …

27 c#  unit-testing  domain-driven-design  xunit 

ฉันกำลังตั้งค่าขั้นตอนแรกของฉันในการออกแบบที่ขับเคลื่อนด้วยโดเมนซื้อสมุดสีฟ้าและทั้งหมดและฉันพบว่าตัวเองเห็นวิธีสามวิธีในการนำโซลูชันมาใช้ สำหรับบันทึก: ฉันไม่ได้ใช้ CQRS หรือการจัดหากิจกรรม สมมติว่าคำขอของผู้ใช้มาในเลเยอร์บริการแอพพลิเคชัน ตรรกะทางธุรกิจสำหรับคำขอนั้นคือ (ด้วยเหตุผลใดก็ตาม) ที่แยกออกเป็นวิธีการในเอนทิตีและวิธีการในบริการโดเมน ฉันจะเรียกวิธีการเหล่านั้นได้อย่างไร ตัวเลือกที่ฉันรวบรวมได้มีดังนี้: ให้บริการแอปพลิเคชันโทรทั้งสองวิธี ใช้วิธีการฉีด / ส่งสองครั้งเพื่อฉีดบริการโดเมนลงในเอนทิตีปล่อยให้เอนทิตีทำสิ่งนั้นแล้วปล่อยให้มันเรียกวิธีการบริการโดเมน (หรือวิธีอื่น ๆ ให้บริการโดเมนเรียกวิธีการในนิติบุคคล) เพิ่มเหตุการณ์โดเมนในวิธีเอนทิตีซึ่งเป็นตัวจัดการที่เรียกใช้บริการโดเมน (ประเภทของกิจกรรมโดเมนที่ฉันกำลังพูดถึงคือ: http://www.udidahan.com/2009/06/14/domain-events-salvation/ ) ฉันคิดว่าสิ่งเหล่านี้ใช้ได้จริง แต่ฉันไม่สามารถเลือกระหว่างพวกเขาได้ ฉันเคยคิดเกี่ยวกับเรื่องนี้มานานแล้วและฉันก็มาถึงจุดที่ฉันไม่เห็นความแตกต่างทางความหมายระหว่างทั้งสาม คุณรู้แนวทางบางอย่างเมื่อใช้อะไร

27 c#  patterns-and-practices  domain-driven-design 

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

27 design-patterns  architecture  domain-driven-design 

สมมติว่าเรากำลังสร้างโมเดลโดยใช้ DDD แบบฟอร์มอาจมีกฎเกณฑ์ทางธุรกิจบางประเภทที่เกี่ยวข้องกับมัน - บางทีคุณจะต้องระบุรายได้หากคุณไม่ได้เป็นนักเรียนและคุณจะต้องระบุรายชื่อบุตรหลานของคุณหากคุณระบุว่าคุณแต่งงานแล้ว และถ้าคุณระบุประเทศก็ควรมีประเทศที่ถูกต้อง การตรวจสอบความถูกต้องเช่นนี้อยู่ในโดเมนหรือเลเยอร์แอปพลิเคชันหรือไม่ ปัญหาอื่น ๆ ที่ฉันกำลังพิจารณา: เฟรมเวิร์กบางตัวเช่น Laravel จัดเตรียมกฎการตรวจสอบที่สามารถตรวจสอบอินพุตก่อนที่คำร้องขอจะเข้าควบคุม DDD แตกหรือไม่หากการตรวจสอบเสร็จในระดับนั้น สำหรับกรณีเช่นการพิจารณาว่าประเทศนั้นถูกต้องหรือไม่ฉันมักจะสอบถามตารางฐานข้อมูลของทุกประเทศในโลก อย่างไรก็ตามใน DDD สิ่งนี้น่าจะเป็น (จากความเข้าใจของฉัน) ที่ต้องทำในเลเยอร์โดเมน เลเยอร์โดเมนได้รับอนุญาตให้เข้าถึงฐานข้อมูลหรือฉันต้องใช้การค้นหาที่ไม่ใช่ SQL เพื่อกำหนดประเทศที่ถูกต้องหรือไม่ จำเป็นหรือไม่ที่จะต้องตรวจสอบอินพุตทั้งที่แอ็พพลิเคชันและเลเยอร์โดเมน?

26 domain-driven-design 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน3 ปีที่ผ่านมา ฉันได้ยินเกี่ยวกับ Domain Driven Development จากผู้พัฒนาในพื้นที่ เขาพูดถึงมันเหมือนเป็นเรื่องเกี่ยวกับกระสุนเงินกับความต้องการที่เปลี่ยนแปลง ผมอ่านวิกิพีเดีย ยังไม่ชัดเจนเกินไป "3D" ในแง่การปฏิบัติคืออะไร? น่าทึ่งจริง ๆ ที่ตอนนี้การสร้างไดอะแกรมคลาส UML ล้าสมัยไปแล้วหรือ

24 domain-driven-design 

ในบทความนี้ผู้เขียนอ้างว่า บางครั้งจำเป็นต้องเปิดเผยการดำเนินการใน API ที่โดยทั่วไปจะไม่สงบ และนั่น หาก API มีการดำเนินการมากเกินไปนั่นเป็นข้อบ่งชี้ว่ามันได้รับการออกแบบด้วยมุมมอง RPC แทนที่จะใช้หลักการ RESTful หรือ API ที่เป็นปัญหานั้นเหมาะสมสำหรับรุ่นประเภท RPC โดยธรรมชาติ สิ่งนี้สะท้อนถึงสิ่งที่ฉันได้อ่านและได้ยินที่อื่นเช่นกัน อย่างไรก็ตามฉันพบว่ามันค่อนข้างสับสนและฉันต้องการทำความเข้าใจเกี่ยวกับเรื่องนี้ให้ดีขึ้น ตัวอย่างฉัน: การปิด VM ผ่านอินเตอร์เฟส REST ฉันคิดว่ามีสองวิธีที่แตกต่างกันในการสร้างแบบจำลองการปิดระบบของ VM แต่ละวิธีอาจมีรูปแบบต่างกันเล็กน้อย แต่เราจะมุ่งเน้นไปที่ความแตกต่างพื้นฐานที่สุดในตอนนี้ 1. แก้ไขคุณสมบัติสถานะของทรัพยากร PATCH /api/virtualmachines/42 Content-Type:application/json { "state": "shutting down" } (หรืออีกวิธีหนึ่งPUTบนทรัพยากรย่อย/api/virtualmachines/42/state) VM จะปิดระบบในพื้นหลังและในเวลาต่อมาขึ้นอยู่กับว่าการปิดเครื่องจะสำเร็จหรือไม่สถานะอาจได้รับการปรับปรุงภายในด้วย "ปิด" 2. ใส่หรือโพสต์บนคุณสมบัติการกระทำของทรัพยากร PUT /api/virtualmachines/42/actions Content-Type:application/json { "type": "shutdown" } …

24 rest  domain-driven-design  api-design  cqrs 

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

23 object-oriented  domain-driven-design  orm  serialization 

ฉันไม่คิดว่าตัวเองเป็นผู้เชี่ยวชาญ DDD แต่ในฐานะสถาปนิกโซลูชันพยายามใช้แนวทางปฏิบัติที่ดีที่สุดเท่าที่จะทำได้ ฉันรู้ว่ามีการถกเถียงกันอย่างมากมายเกี่ยวกับ "สไตล์" setter ของมือโปรและผู้ต่อต้านใน DDD และฉันสามารถเห็นการโต้แย้งทั้งสองด้าน ปัญหาของฉันคือฉันทำงานเป็นทีมที่มีทักษะความรู้และประสบการณ์ที่หลากหลายซึ่งหมายความว่าฉันไม่สามารถไว้วางใจได้ว่านักพัฒนาทุกคนจะทำสิ่งที่ "ถูกต้อง" ตัวอย่างเช่นหากวัตถุโดเมนของเราได้รับการออกแบบเพื่อให้การเปลี่ยนแปลงสถานะภายในของวัตถุดำเนินการโดยวิธีการ แต่ให้ผู้ตั้งค่าทรัพย์สินสาธารณะบางคนจะหลีกเลี่ยงไม่ได้ตั้งค่าคุณสมบัติแทนการเรียกวิธีการ ใช้ตัวอย่างนี้: public class MyClass { public Boolean IsPublished { get { return PublishDate != null; } } public DateTime? PublishDate { get; set; } public void Publish() { if (IsPublished) throw new InvalidOperationException("Already published."); PublishDate = DateTime.Today; …

23 unit-testing  domain-driven-design 

ฉันได้อ่านบทความจำนวนมากเมื่อเร็ว ๆ นี้ที่อธิบายครอบงำจิตใจดั้งเดิมเป็นกลิ่นรหัส มีประโยชน์สองประการในการหลีกเลี่ยงความหลงใหลดั้งเดิม: ทำให้โมเดลโดเมนชัดเจนยิ่งขึ้น ตัวอย่างเช่นฉันสามารถพูดคุยกับนักวิเคราะห์ธุรกิจเกี่ยวกับรหัสไปรษณีย์แทนที่จะเป็นสตริงที่มีรหัสไปรษณีย์ การตรวจสอบทั้งหมดอยู่ในที่เดียวแทนที่จะใช้ข้ามแอปพลิเคชัน มีบทความมากมายที่อธิบายเมื่อมันเป็นกลิ่นรหัส ตัวอย่างเช่นฉันสามารถเห็นประโยชน์ของการลบความหลงใหลดั้งเดิมสำหรับรหัสโพสต์เช่นนี้: public class Address { public ZipCode ZipCode { get; set; } } นี่คือตัวสร้างของรหัสไปรษณีย์: public ZipCode(string value) { // Perform regex matching to verify XXXXX or XXXXX-XXXX format _value = value; } คุณจะทำลายหลักการDRYโดยวางตรรกะการตรวจสอบความถูกต้องทุกที่ที่ใช้รหัสไปรษณีย์ อย่างไรก็ตามสิ่งที่เกี่ยวกับวัตถุต่อไปนี้: วันเดือนปีเกิด: ตรวจสอบว่ามากเกินใจและน้อยกว่าวันนี้วันที่ เงินเดือน: ตรวจสอบว่ามากกว่าหรือเท่ากับศูนย์ คุณจะสร้างวัตถุ DateOfBirth และวัตถุเงินเดือนหรือไม่ ประโยชน์คือคุณสามารถพูดคุยเกี่ยวกับพวกเขาเมื่ออธิบายรูปแบบโดเมน …

22 c#  domain-driven-design  domain-model  abstraction  modeling