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

ในการออกแบบการขับเคลื่อนโดเมน Domain Layer สามารถมีบริการ (ดั้งเดิม) หลายอย่าง ตัวอย่างเช่นสำหรับโดเมนผู้ใช้เราอาจมี: UserFactory ที่สร้างวัตถุผู้ใช้ด้วยวิธีที่ต่างกัน UserRepository ซึ่งรับผิดชอบในการโต้ตอบกับ Persistence Services ในชั้นโครงสร้างพื้นฐาน UserService ใน Domain Layer นั้นเป็นเพียงแค่ผู้ไกล่เกลี่ยและ / หรือส่วนหน้าของบริการทั้งสองและโครงสร้างพื้นฐานของเลเยอร์หรือมีมากกว่านั้นหรือไม่

13 object-oriented  object-oriented-design  domain-driven-design 

ฉันเข้าสู่แนวคิดเกี่ยวกับการออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD) และพบหลักการบางอย่างที่แปลกประหลาดโดยเฉพาะอย่างยิ่งเกี่ยวกับการแยกโดเมนและรูปแบบการคงอยู่ นี่คือความเข้าใจพื้นฐานของฉัน: บริการบนชั้นแอปพลิเคชัน (จัดเตรียมชุดคุณสมบัติ) ร้องขอวัตถุโดเมนจากที่เก็บที่จำเป็นต้องใช้เพื่อทำหน้าที่ของมัน การนำไปใช้อย่างเป็นรูปธรรมของที่เก็บนี้ดึงข้อมูลจากที่เก็บข้อมูลที่ถูกนำไปใช้ บริการบอกวัตถุโดเมนซึ่งสรุปทางตรรกะทางธุรกิจเพื่อดำเนินงานบางอย่างที่แก้ไขสถานะของมัน บริการบอกที่เก็บเพื่อคงออบเจ็กต์โดเมนที่ถูกแก้ไข ที่เก็บข้อมูลจำเป็นต้องแมปวัตถุโดเมนกลับไปเป็นตัวแทนที่สอดคล้องกันในการจัดเก็บ ตอนนี้จากข้อสมมติข้างต้น โฆษณา 2: ดูเหมือนว่าแบบจำลองโดเมนจะโหลดวัตถุโดเมนทั้งหมด (รวมถึงเขตข้อมูลและการอ้างอิงทั้งหมด) แม้ว่าจะไม่จำเป็นสำหรับฟังก์ชันที่ร้องขอก็ตาม การโหลดอาจไม่สามารถทำได้หากมีการอ้างอิงวัตถุโดเมนอื่นเว้นแต่คุณจะโหลดวัตถุโดเมนเหล่านั้นด้วยและวัตถุทั้งหมดที่อ้างอิงในทางกลับกันเป็นต้น การโหลด Lazy คำนึงถึงซึ่งหมายความว่าคุณเริ่มทำการค้นหาวัตถุโดเมนของคุณซึ่งควรจะเป็นความรับผิดชอบของที่เก็บในตอนแรก เมื่อพิจารณาถึงปัญหานี้ดูเหมือนว่าวิธีการโหลดวัตถุโดเมนที่ถูกต้องจะมีฟังก์ชันการโหลดเฉพาะสำหรับแต่ละกรณีการใช้งาน ฟังก์ชั่นเฉพาะเหล่านี้จะโหลดข้อมูลที่จำเป็นโดยกรณีการใช้งานที่ถูกออกแบบมาเท่านั้น นี่คือสิ่งที่น่าอึดอัดใจที่เข้ามาเล่น: อย่างแรกฉันจะต้องรักษาจำนวนมากของการโหลดฟังก์ชั่นสำหรับแต่ละการใช้งานของพื้นที่เก็บข้อมูลและวัตถุโดเมนจะจบลงในรัฐที่ไม่สมบูรณ์ที่ดำเนินการnullในสาขาของพวกเขา ในทางเทคนิคหลังควรจะไม่มีปัญหาเพราะถ้าไม่ได้โหลดค่ามันไม่ควรจะจำเป็นต้องใช้ฟังก์ชั่นที่ร้องขอมันต่อไป ถึงกระนั้นมันก็น่าอึดอัดใจและอาจเป็นอันตรายได้ โฆษณา 3: วัตถุโดเมนจะตรวจสอบข้อ จำกัด ที่ไม่ซ้ำกันอย่างไรเมื่อการก่อสร้างถ้ามันไม่มีความคิดใด ๆ ของพื้นที่เก็บข้อมูล? ตัวอย่างเช่นถ้าฉันต้องการสร้างใหม่Userด้วยหมายเลขประกันสังคมที่ไม่ซ้ำกัน (ซึ่งได้รับ) ความขัดแย้งที่เร็วที่สุดจะเกิดขึ้นเมื่อขอให้พื้นที่เก็บข้อมูลบันทึกวัตถุเฉพาะในกรณีที่มีข้อ จำกัด ที่ไม่ซ้ำกันที่กำหนดไว้ในฐานข้อมูล มิฉะนั้นฉันสามารถหา a ที่Userมีประกันสังคมที่กำหนดและรายงานข้อผิดพลาดในกรณีที่มันมีอยู่ก่อนที่จะสร้างใหม่ แต่จากนั้นการตรวจสอบข้อ จำกัด จะอาศัยอยู่ในบริการไม่ใช่ในวัตถุโดเมนที่เป็นของพวกเขา ฉันเพิ่งรู้ว่าวัตถุโดเมนได้รับอนุญาตเป็นอย่างดีในการใช้ที่เก็บ (ฉีด) สำหรับการตรวจสอบ โฆษณา 5: …

13 domain-driven-design  domain-model  persistence 

การใช้งานทั่วไปของแหล่งเก็บข้อมูล DDD ดูไม่ OO มากเช่นsave()วิธีการ: package com.example.domain; public class Product { /* public attributes for brevity */ public String name; public Double price; } public interface ProductRepo { void save(Product product); } ส่วนโครงสร้างพื้นฐาน: package com.example.infrastructure; // imports... public class JdbcProductRepo implements ProductRepo { private JdbcTemplate = ... public void save(Product …

12 design-patterns  object-oriented  domain-driven-design 

ข้อสงวนสิทธิ์แรก: ฉันไม่รู้จริงๆว่าคำถามนี้เหมาะกับเว็บไซต์นี้หรือไม่ แต่ฉันก็ยังพบว่าเป็นคำถามที่เกี่ยวข้องไม่ใช่เฉพาะกับฉัน แต่สำหรับคนอื่น ๆ ที่เป็นผู้เริ่มต้น หากคำถามสามารถปรับปรุงให้เหมาะกับที่นี่โปรดชี้ให้เห็นความคิดเห็น int หากมันไม่พอดีโปรดแจ้งให้ฉันทราบด้วยและหากเป็นไปได้โปรดแจ้งให้เราทราบว่าสามารถพูดคุยเรื่องนี้ได้ที่ไหนเพราะฉันไม่พบฟอรัมที่ดีสำหรับเรื่องนี้ ฉันเรียนรู้ที่จะเขียนโปรแกรมในปี 2009 เมื่อฉันเรียน PHP ต่อมาในปี 2012 ฉันย้ายไปที่ C # และ. NET อย่างไรก็ตามการเขียนโค้ดไม่ใช่ปัญหาการจดอัลกอริธึมไม่ใช่ปัญหาของฉัน ปัญหาที่เกิดขึ้นจริงของฉันคือการรู้ว่าสิ่งที่จะต้องมีการเข้ารหัสเพื่อให้บรรลุความต้องการและการที่มันจะต้องมีการเข้ารหัส หลักสูตรส่วนใหญ่ที่มีอยู่บนเว็บจัดการวิธีการเขียนโค้ดในภาษาบางภาษาวิธีใช้ API บางชุด ฯลฯ นั่นไม่ใช่ประเด็นของฉันที่นี่ ในปีที่ผ่านมาฉันได้อ่านสิ่งต่างๆมากมาย: การวิเคราะห์และออกแบบเชิงวัตถุรูปแบบการออกแบบการออกแบบโดยใช้โดเมนเป็นต้น ฉันเข้าใจตัวอย่างเช่นหลักการ SOLID แนวคิดหลักบางประการของ DDD เช่นความจำเป็นในการมีส่วนร่วมของผู้เชี่ยวชาญด้านโดเมนการพัฒนาภาษาที่แพร่หลายและอื่น ๆ ฉันจะกล้าพูดว่าฉันมีพื้นฐานทางทฤษฎีอย่างน้อยเหมาะสม แต่เมื่อพูดถึงการฝึกฝนฉันรู้สึกว่าฉันเป็นหายนะ เมื่อไม่นานมานี้ฉันจำเป็นต้องพัฒนาระบบการเงินที่ถูกพัฒนาโดยบุคคลอื่นต่อไป มันเป็น "ระบบเก่า" ที่พัฒนาด้วย C # และ WinForms นี่เป็นครั้งแรกที่ฉันเลือกโครงการที่มีความซับซ้อนของโดเมนจริงด้วยกฎเกณฑ์ทางธุรกิจมากมายและอื่น ๆ ฉันยอมรับว่าเมื่อฉันได้รับข้อกำหนดเกือบตลอดเวลาฉันคิดว่า "จะทำอย่างไรในโลกนี้?" - …

12 architecture  object-oriented-design  domain-driven-design  requirements  engineering 

Persistence Ignoranceเป็นแอพพลิเคชั่นของหลักการความรับผิดชอบเดี่ยวซึ่งในทางปฏิบัติหมายความว่า Domain Objects ( DO ) ไม่ควรมีรหัสที่เกี่ยวข้องกับการคงอยู่ แต่ควรจะมีตรรกะของโดเมนเท่านั้น a) ฉันถือว่านี่หมายความว่ารหัสที่ติดต่อเลเยอร์ที่ต่ำกว่า (เช่นชั้นที่มีอยู่) อยู่นอกโมเดลโดเมนในคลาสอื่น ( OC ) ของเลเยอร์ตรรกะทางธุรกิจหรือไม่ b) หากการสันนิษฐานของฉันภายใต้a)ถูกต้องดังนั้นDOพูดว่าCustomerไม่มีวิธีการเช่นGetCustomersหรือGetCustomerByID? c) หากสมมุติฐานของฉันภายใต้a)และb)ถูกต้องและสมมติว่าCustomerวัตถุโดเมนใช้การโหลดแบบขี้เกียจสำหรับคุณสมบัติบางอย่างนั้นCustomerตรรกะภายในของบางจุดจะต้องติดต่อOCซึ่งจะดึงข้อมูลที่ได้รับการแก้ไข แต่ถ้าCustomerต้องการติดต่อOCเพื่อรับข้อมูลที่ถูกหักล้างเราไม่สามารถอ้างสิทธิ์ได้จริงๆว่า Domain Objects ไม่มีตรรกะที่เกี่ยวข้องกับการคงอยู่หรือไม่! ขอบคุณ ตอบกลับไปยัง jkohlhepp 1) ผมถือว่าOrderProviderและCustomerProviderชั้นเรียนที่มีอยู่ภายในชั้นตรรกะทางธุรกิจ? 2) ฉันรวบรวมจากคำตอบของคุณว่าสมมติฐานของฉันภายใต้ข)ถูกต้องหรือไม่ 3) ... ฉันจะตรวจสอบเพื่อดูว่าฟิลด์คำสั่งซื้อส่วนตัวบางส่วนมีการเติมข้อมูลหรือไม่หรือไม่ ถ้ามันเป็นโมฆะ ... แต่เท่าที่ฉันสามารถบอกได้ทันทีที่รหัสโดเมนจำเป็นต้องตรวจสอบว่าorderมีการเติมข้อมูลในฟิลด์ส่วนตัวหรือไม่และถ้าไม่ติดต่อ OrderProvider เรากำลังละเมิดหลักการPIอยู่แล้ว!

12 design-patterns  domain-driven-design  domain-model  persistence 

ฉันได้อ่านเกี่ยวกับ DDD มาหลายวันแล้วและต้องการความช่วยเหลือในการออกแบบตัวอย่างนี้ กฎทั้งหมดของ DDD ทำให้ฉันสับสนมากกับวิธีที่ฉันควรจะสร้างอะไรเลยเมื่อวัตถุโดเมนไม่ได้รับอนุญาตให้แสดงวิธีการในชั้นแอพลิเคชัน; มีที่ไหนอีกที่จะจัดการกับพฤติกรรม? ที่เก็บไม่ได้รับอนุญาตให้ถูกฉีดเข้าไปในเอนทิตีและเอนทิตี้ของตัวเองจึงต้องทำงานกับรัฐ ถ้าอย่างนั้นเอนทิตีต้องรู้อะไรจากโดเมน แต่วัตถุเอนทิตีอื่น ๆ ไม่ได้รับอนุญาตให้ฉีด? บางสิ่งเหล่านี้มีเหตุผลสำหรับฉัน แต่บางอย่างไม่ ฉันยังไม่พบตัวอย่างที่ดีของวิธีสร้างคุณลักษณะทั้งหมดเนื่องจากทุกตัวอย่างเกี่ยวกับคำสั่งซื้อและผลิตภัณฑ์ทำซ้ำตัวอย่างอื่น ๆ ซ้ำแล้วซ้ำอีก ฉันเรียนรู้ได้ดีที่สุดจากการอ่านตัวอย่างและพยายามสร้างคุณสมบัติโดยใช้ข้อมูลที่ฉันได้รับเกี่ยวกับ DDD ในตอนนี้ ฉันต้องการให้คุณช่วยชี้ให้เห็นสิ่งที่ฉันทำผิดและวิธีการแก้ไขโดยเฉพาะอย่างยิ่งกับรหัสว่า "ฉันจะไม่ recomment ทำ X และ Y" ยากที่จะเข้าใจในบริบทที่ทุกอย่างเพิ่งกำหนดชัดเจนแล้ว ถ้าฉันไม่สามารถฉีดเอนทิตี้เข้าไปในที่อื่นได้จะง่ายกว่าที่จะเห็นวิธีการทำอย่างถูกต้อง ในตัวอย่างของฉันมีผู้ใช้และผู้ดูแล ผู้ดำเนินรายการสามารถแบนผู้ใช้ แต่ด้วยกฎธุรกิจ: เพียง 3 ต่อวัน ฉันพยายามตั้งค่าคลาสไดอะแกรมเพื่อแสดงความสัมพันธ์ (รหัสด้านล่าง): interface iUser { public function getUserId(); public function getUsername(); } class User implements …

12 architecture  domain-driven-design 

เรากำลังพยายามย้ายข้อมูลจากเลเยอร์บริการที่ป่องของเราไปยังเลเยอร์โดเมนของเราโดยใช้วิธี DDD ขณะนี้เรามีตรรกะทางธุรกิจจำนวนมากในบริการของเราซึ่งกระจายไปทั่วสถานที่และไม่ได้รับประโยชน์จากการสืบทอด เรามีโดเมนระดับกลางซึ่งเป็นจุดสนใจของงานส่วนใหญ่ของเรา - การค้าขาย วัตถุการค้าจะรู้วิธีกำหนดราคาตัวเองวิธีประเมินความเสี่ยงตรวจสอบตัวเอง ฯลฯ จากนั้นเราสามารถแทนที่เงื่อนไขด้วย polymorphism เช่น SimpleTrade จะตั้งราคาเองทางเดียว แต่ ComplexTrade จะกำหนดราคาอีกทางหนึ่ง อย่างไรก็ตามเรามีความกังวลว่าสิ่งนี้จะขยายชั้นการค้า มันควรจะเป็นหน้าที่ของการประมวลผลของตัวเอง แต่ขนาดของชั้นเรียนจะเพิ่มขึ้นแบบทวีคูณเมื่อมีการเพิ่มคุณสมบัติมากขึ้น ดังนั้นเราจึงมีทางเลือก: ใส่ตรรกะการประมวลผลในระดับการค้า ตรรกะการประมวลผลตอนนี้เป็นแบบ polymorphic ตามประเภทของการค้า แต่ขณะนี้ชั้นการค้ามีความรับผิดชอบหลายอย่าง (การกำหนดราคาความเสี่ยง ฯลฯ ) และมีขนาดใหญ่ ใส่ตรรกะการประมวลผลลงในคลาสอื่นเช่น TradePricingService ไม่มี polymorphic อีกต่อไปกับแผนภูมิการสืบทอดการค้า แต่คลาสมีขนาดเล็กและง่ายต่อการทดสอบ อะไรคือแนวทางที่แนะนำ

12 object-oriented  design  domain-driven-design 

ฉันเพิ่งอ่านข้อโต้แย้งจำนวนมากต่อต้านการใช้รูปแบบพื้นที่เก็บข้อมูลกับ Entity Framework ORM ที่ทรงพลังเนื่องจากมีการรวมฟังก์ชั่นที่คล้ายกับพื้นที่เก็บข้อมูลพร้อมกับฟังก์ชั่นหน่วยการทำงานเช่นกัน อีกข้อโต้แย้งต่อการใช้รูปแบบสำหรับสถานการณ์เช่นการทดสอบหน่วยคือรูปแบบที่เก็บเป็นสิ่งที่เป็นนามธรรมเนื่องจากการใช้งานทั่วไปมีประโยชน์มากขึ้น IQueryable ข้อโต้แย้งเกี่ยวกับการใช้รูปแบบพื้นที่เก็บข้อมูลมีเหตุผลสำหรับฉัน แต่วิธีการทางเลือกของ abstractions ที่แนะนำมักทำให้เกิดความสับสนมากขึ้นและดูเหมือนจะเกินความเป็นปัญหาเช่นกัน วิธีการแก้ปัญหาของ Jimmy Bogards ดูเหมือนจะเป็นการผสมผสานของนามธรรมที่ออกไป แต่ยังแนะนำสถาปัตยกรรมของเขาเอง https://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/ อีกตัวอย่างของที่เก็บที่ไม่จำเป็น .... แต่ใช้สถาปัตยกรรมของฉัน! http://blog.gauffin.org/2012/10/22/griffin-decoupled-the-queries/ อื่น ... http://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework ฉันไม่พบวิธีการแทนที่ที่ชัดเจนหรือทางเลือกแทนวิธีการเก็บข้อมูลแบบ "ซับซ้อนมากเกินไป" ซึ่งไม่ได้มีการออกแบบตัวเองมากกว่า

12 domain-driven-design  entity-framework  orm  nhibernate  repository-pattern 

โดยทั่วไปฉันพยายามจะคลุมหัวแนวคิดของCQRSและแนวคิดที่เกี่ยวข้อง แม้ว่า CQRS ไม่จำเป็นต้องรวมการส่งข้อความและการจัดหากิจกรรม แต่ดูเหมือนว่าจะเป็นการผสมผสานที่ดี ได้รับกรณีการใช้งานสำหรับการเปลี่ยนแปลงสถานะสำหรับบางสิ่ง (พูดเพื่ออัปเดตคำถามเกี่ยวกับ SO) คุณจะพิจารณาว่าโฟลว์ต่อไปนี้ถูกต้องหรือไม่ ระบบออกรวม UpdateQuestionCommand ซึ่งอาจแยกออกเป็นสองคำสั่งเล็ก: UpdateQuestion ซึ่งมีการกำหนดเป้าหมายที่ Root Aggregate คำถามและ UpdateUserAction (เพื่อนับคะแนน ฯลฯ ) กำหนดเป้าหมายที่ User Aggregate Root สิ่งเหล่านี้ส่งแบบอะซิงโครนัสโดยใช้การส่งข้อความแบบจุดต่อจุด รากรวมทำสิ่งของพวกเขาและถ้าทุกอย่างดำเนินไปได้ดีกับเหตุการณ์ QuestionUpdated และ UserActionUpdated ตามลำดับซึ่งมีสถานะที่ถูกเอาต์ซอร์ซไปยัง Event Store .. เพื่อที่จะยืนยัน yadayada ให้เสร็จสมบูรณ์ไม่ใช่จุดที่นี่จริงๆ เหตุการณ์เหล่านี้จะถูกวางในคิว pub / sub เพื่อออกอากาศ ผู้สมัครสมาชิกใด ๆ (ซึ่งมีแนวโน้มว่าจะมีหนึ่งหรือหลายโปรเจ็คเตอร์ที่สร้างมุมมองอ่าน) มีอิสระที่จะสมัครสมาชิกกับเหตุการณ์เหล่านี้ คำถามทั่วไป: เป็นวิธีปฏิบัติที่ดีที่สุดจริง ๆ หรือไม่ที่คำสั่งนั้นสื่อสารแบบจุดต่อจุด …

12 domain-driven-design  cqrs  event-sourcing 

บทเรียนจำนวนมากเกี่ยวกับ DDD ที่ฉันศึกษาส่วนใหญ่จะครอบคลุมทฤษฎี พวกเขาทั้งหมดมีตัวอย่างรหัสพื้นฐาน (Pluralsight และคล้ายคลึงกัน) บางคนพยายามสร้างบทเรียนที่ครอบคลุม DDD ด้วย EF บนเว็บ หากคุณเริ่มศึกษาพวกเขาเพียงชั่วครู่ - คุณสังเกตได้อย่างรวดเร็วว่าพวกเขาแตกต่างกันมาก บางคนแนะนำให้แอพพลิเคชั่นมีน้อยที่สุดและเพื่อหลีกเลี่ยงการแนะนำเลเยอร์เพิ่มเติมเช่นที่เก็บข้อมูลด้านบนของ EFคนอื่น ๆ กำลังสร้างเลเยอร์เพิ่มเติมอย่างแน่นอนซึ่งมักจะละเมิด SRP ด้วยการฉีดDbContextเข้าไปใน Aggregate Roots ฉันขอโทษอย่างมากถ้าฉันถามคำถามตามความคิดเห็น แต่ ... เมื่อมาถึงการปฏิบัติ - Entity Framework เป็นหนึ่งใน ORMs ที่ทรงพลังและใช้กันอย่างแพร่หลาย คุณจะไม่พบหลักสูตรที่ครอบคลุมที่ครอบคลุม DDD ด้วยโชคไม่ดี ประเด็นสำคัญ: Entity Framework นำ UoW & Repository ( DbSet) ออกจากกล่อง รุ่นของคุณกับ EF มีคุณสมบัติการนำทาง กับ EF …

12 c#  design-patterns  object-oriented-design  domain-driven-design  entity-framework 

ตามที่ฉันเข้าใจใน DDD มีความเหมาะสมที่จะใช้รูปแบบพื้นที่เก็บข้อมูลที่มีรูทรวม คำถามของฉันคือฉันควรส่งคืนข้อมูลเป็นนิติบุคคลหรือวัตถุโดเมน / DTO หรือไม่ บางทีรหัสบางอย่างจะอธิบายคำถามของฉันเพิ่มเติม: เอกลักษณ์ public class Customer { public Guid Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } } ฉันควรทำอะไรแบบนี้ public Customer GetCustomerByName(string name) { /*some code*/ } หรืออะไรแบบนี้ public class CustomerDTO { public …

11 c#  domain-driven-design  repository-pattern 

ฉันต้องการใช้แอปพลิเคชันแรกของฉันโดยใช้รูปแบบ CQRS พร้อมกับการจัดหากิจกรรม ฉันสงสัยว่าการสร้างรากรวมควรได้รับการจัดการอย่างเหมาะสมอย่างไร สมมติว่ามีคนส่งคำสั่ง CreateItem ควรจัดการอย่างไร? รายการเหตุการณ์ที่สร้างขึ้นควรเก็บไว้ที่ไหน เป็นกิจกรรมแรกของรายการใหม่หรือไม่ หรือฉันควรจะมีรายการ ItemList บางอย่างที่รวมรายการทั้งหมดและรายการเหตุการณ์ประกอบด้วยรายการของ ItemCreated เท่านั้น Udi Dahan ไม่แนะนำให้สร้างรากรวมและมักจะใช้วิธีดึงข้อมูลบางอย่างแทน แต่วิธีที่ฉันสามารถดึงข้อมูลบางอย่างที่ใหม่และแน่นอนไม่มี ID ใด ๆ ที่ได้รับมอบหมาย ฉันเข้าใจความคิดที่อยู่เบื้องหลังและมันค่อนข้างสมเหตุสมผลที่จะคิดว่าวัตถุใหม่เป็นวัตถุที่มีสถานะเป็นศูนย์ซึ่งประกอบด้วยเหตุการณ์ที่ตอบกลับเป็นศูนย์ แต่ฉันจะใช้มันได้อย่างไร ฉันควรจะมีวิธีการที่แตกต่างกันในพื้นที่เก็บข้อมูลของฉันเช่นgetNewItem()หรือทำให้get(id)วิธีการของฉันยอมรับOptional<ItemId>แทน? แก้ไข: หลังจากการขุดสักพักฉันพบว่าการใช้รูปแบบดังกล่าวน่าสนใจจริง ๆโดยใช้นักแสดง ผู้เขียนแทนที่จะสร้างผลรวมดึงข้อมูลจากที่เก็บบางประเภทด้วย UUID ที่สร้างขึ้นใหม่ ข้อเสียเปรียบของวิธีนี้คือเขาอนุญาตให้มีสถานะที่ไม่สอดคล้องกันชั่วคราว ฉันยังสงสัยว่าฉันสามารถใช้deleteวิธีการด้วยวิธีดังกล่าวได้อย่างไร เพียงเพิ่มเหตุการณ์ที่ถูกลบไปยังรายการกิจกรรมของการรวมหรือไม่

11 domain-driven-design  repository  cqrs  event-sourcing 

ฉันกำลังมองหาการสร้างโซลูชันใหม่ที่เป็นแบบแยกส่วนโดยธรรมชาติและต้องการสร้างโครงสร้างที่รองรับการออกแบบนั้นเพื่อให้สามารถขยายตัวในอนาคตได้อย่างง่ายดายแยกข้อกังวลออกใบอนุญาตโดยโมดูล ฯลฯ สิ่งที่ฉันทำส่วนใหญ่คือ พบได้บนเว็บเกี่ยวกับแอปพลิเคชันแบบแยกส่วนหรือคอมโพสิตคือ UI เป็นศูนย์กลางมุ่งเน้นไปที่ Silverlight, WPF และอื่น ๆ ในกรณีของฉันฉันกำลังพัฒนาแอพพลิเคชั่นบริการ WCF ที่นักพัฒนาอื่น ๆ พื้นหลัง เป้าหมายของโครงการของฉันคือการสร้างแหล่งที่มาแบบรวมศูนย์ของตรรกะทางธุรกิจ / โดเมนเพื่อสนับสนุนแอปพลิเคชันทางธุรกิจของเราหลายอย่างที่กำลังทำซ้ำกระบวนการกฎและอื่น ๆ และแม้ว่าจะไม่ได้รับประโยชน์จากโมดูลทั้งหมด โอกาสในการสร้างกรอบที่จะใช้ประโยชน์จากส่วนที่เราสามารถใช้ประโยชน์จาก ฉันเริ่มต้นการออกแบบโดยดูที่ API ที่เปิดเผยโดยแอปพลิเคชันบริการ เป็นที่ชัดเจนว่าบริการสามารถแยกออกไปตามสายโมดูลาร์ที่ฉันกำลังพิจารณา ตัวอย่างเช่นฉันจะมี FinanceService, InventoryService, PersonnelService และบริการอื่น ๆ ที่จัดกลุ่มการดำเนินงานบริการของฉันเพื่อให้มีการทำงานร่วมกันสูงใน API ในขณะที่การมีเพศสัมพันธ์ต่ำดังนั้นลูกค้าจะต้องใช้บริการที่เกี่ยวข้องกับแอปพลิเคชันของตน ฉันรู้สึกว่าฉันสามารถมีโมดูลแยกต่างหากสำหรับแต่ละบริการเหล่านี้เช่น MyApp.Finance, MyApp.Inventory, My.Personnel และอื่น ๆ ความกังวลแบบตัดขวางและประเภทที่แชร์จะอยู่ในชุดประกอบ MyApp ที่ใช้ร่วมกัน จากที่นี่ฉันจะได้รับการผูกเล็กน้อย (โอ้ฉันควรพูดถึงว่าฉันจะใช้คอนเทนเนอร์ IoC สำหรับ Dependency Injection เพื่อให้แอปพลิเคชันมีการเชื่อมต่ออย่างหลวม …

11 architecture  domain-driven-design  wcf  soa  modules 

ฉันกำลังเรียน DDD และฉันกำลังคิดจะทิ้งข้อยกเว้นในบางสถานการณ์ ฉันเข้าใจว่าวัตถุไม่สามารถเข้าสู่สถานะที่ไม่ดีดังนั้นที่นี่ยกเว้นได้ดี แต่ในหลาย ๆ ตัวอย่างมีข้อยกเว้นการขว้างปาเช่นถ้าเราพยายามเพิ่มผู้ใช้ใหม่ที่มีอีเมลที่มีอยู่ในฐานข้อมูล public function doIt(UserData $userData) { $user = $this->userRepository->byEmail($userData->email()); if ($user) { throw new UserAlreadyExistsException(); } $this->userRepository->add( new User( $userData->email(), $userData->password() ) ); } ดังนั้นหากผู้ใช้ที่มีอีเมลนี้มีอยู่เราสามารถยกเว้นบริการแอพพลิเคชั่นได้ แต่เราไม่ควรควบคุมการทำงานของแอปพลิเคชันโดยใช้บล็อกการลองจับ วิธีที่ดีที่สุดสำหรับสิ่งนี้คืออะไร?

11 object-oriented  php  programming-practices  domain-driven-design 

คำถามแบบสั้น มันอยู่ในแนวปฏิบัติที่ดีที่สุดของ DDD และ OOP ในการฉีดบริการกับการเรียกเมธอดเอนทิตีหรือไม่? ตัวอย่างรูปแบบยาว สมมติว่าเรามีกรณี Order-LineItems แบบคลาสสิกใน DDD ที่เรามี Domain Entity ชื่อ Order ซึ่งยังทำหน้าที่เป็น Aggregate Root และ Entity นั้นไม่เพียง แต่ประกอบไปด้วย Value Objects แต่ยังเป็นคอลเลกชันของรายการโฆษณา หน่วยงาน สมมติว่าเราต้องการไวยากรณ์ที่คล่องแคล่วในแอปพลิเคชันของเราเพื่อให้เราสามารถทำสิ่งนี้ (สังเกตไวยากรณ์ในบรรทัดที่ 2 ซึ่งเราเรียกgetLineItemsเมธอด) $order = $orderService->getOrderByID($orderID); foreach($order->getLineItems($orderService) as $lineItem) { ... } เราไม่ต้องการฉีด LineItemRepository ใด ๆ ลงใน OrderEntity เนื่องจากเป็นการละเมิดหลักการหลายอย่างที่ฉันสามารถนึกได้ แต่ความคล่องแคล่วของวากยสัมพันธ์เป็นสิ่งที่เราต้องการจริงๆเพราะมันง่ายต่อการอ่านและบำรุงรักษารวมถึงการทดสอบ พิจารณาโค้ดต่อไปนี้โดยสังเกตวิธีgetLineItemsในOrderEntity: interface …

11 object-oriented  php  domain-driven-design  domain-model  lazy-initialization