DDD - รูปแบบโดเมนโลหิตจางเป็นปฏิปักษ์หรือไม่? เราใช้โมเดลโดเมนที่หลากหลายใช่ไหม [ปิด]

รูปแบบของโดเมนโลหิตจางถูกวิพากษ์วิจารณ์เมื่อนานมาแล้วโดยEvans และ Fowlerเนื่องจากเห็นได้ชัดว่ามันขัดกับหลักการเชิงวัตถุ ฯลฯ ชุมชน DDD นั้นสอดคล้องกับข้อความนี้อย่างชัดเจน

อย่างไรก็ตามในช่วงไม่กี่ปีที่ผ่านมามีเสียงไม่เห็นด้วยที่อ้างว่ามันไม่ได้เป็นปฏิปักษ์เลยและเป็นตัวอย่างของการปฏิบัติตามหลักการของโซลิด

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

คำถามของฉันคือ: โมเดลโดเมนโลหิตจางยังถือว่าเป็น antipattern หรือไม่? เราทุกคนทำสิ่งต่าง ๆ (เกี่ยวกับ DDD) ผิดหรือเปล่า? คุณไม่คิดว่าการมีโมเดล Rich Domain ละเมิดหลักการของ SOLID หรือไม่

ADM เป็นรูปแบบที่ดีสำหรับการแก้ปัญหาการให้บริการแบบกระจายเช่นไมโครไซต์ มันเหมาะกับหลายกรณีธุรกิจบนเว็บในปัจจุบัน

พิจารณาว่าเรามีวัตถุโดเมนคำสั่งซื้อหรือไม่ ด้วยวิธีการของ OOP เราจะเพิ่ม Order.Purchase () Order.Cancel () ฯลฯ มันจะทำงานได้ดีในแอพเดสก์ท็อปที่เราเก็บคำสั่งซื้อไว้ในหน่วยความจำและทำหลาย ๆ

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

PurchaseSystemOrder.Purchase()

และ

CancelSystemOrder.Cancel();

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

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

มันสมเหตุสมผลมากกว่าที่จะมีรูปแบบแอนนิกซ์คำสั่งซื้อซึ่งเพิ่งสรุปข้อมูลและเปลี่ยนชื่อบริการของคุณตามนั้น:

PurchaseService.Purchase(Order order)

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

Fowler and Co มาจากพื้นหลังระบบเดียวในโลกของพวกเขาแนวทางของ ADM จะหมายถึงแอพเดียวที่มีบริการแยกต่างหากทั้งหมดเหล่านี้ซึ่งสร้างอินสแตนซ์ในหน่วยความจำและ OrderDTO ถูกส่งผ่านและกลายพันธุ์ สิ่งนี้จะแย่กว่าการวางวิธีการในแบบจำลองการสั่งซื้อที่หลากหลาย

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

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

รวมทั้งการเปลี่ยนเป็นวิธีการเดียวจะต้องมีการอัพเดทส่วนประกอบแบบกระจายทั้งหมดเนื่องจากทั้งหมดขึ้นอยู่กับ Rich Model สำหรับตรรกะของพวกเขา

ฉันไม่มีที่ว่างในรหัสฐานสำหรับสิ่งที่พวกเขาไม่ต้องการ

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

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

DDD เป็นกระบวนทัศน์ที่ยอดเยี่ยมสำหรับบริการไมโครเนื่องจากแนวคิดบริบทที่ล้อมรอบ

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

หลักการ SOLID เป็นชุดของแนวคิด OOP ทั่วไปที่คุณสามารถใช้เพื่อสร้างรหัส OOP ที่ดีขึ้น คุณสามารถเขียนฐานข้อมูล DDD ที่ดีได้โดยใช้มัน

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

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

เฟรมเวิร์กหลายเวิร์มเข้าไปในพื้นที่ภาษาจนกว่าคุณจะไม่สามารถโฆษณางานเป็นงานจาวาอีกต่อไป มันเป็นงาน Java / Spring สิ่งที่พวกเขาทำนอกเหนือจากการทำให้คุณต้องพึ่งพาพวกเขาคือเปลี่ยนภาษาวัตถุประสงค์ทั่วไปให้กลายเป็นรูปแบบของไอ้รุ่นที่ 4

นั่นเป็นวิธีปฏิบัติที่ดีที่สุดหรือรูปแบบการต่อต้านหรือไม่? คุณบอสส่วนใหญ่แค่ใส่ใจว่าคุณสามารถจ้างคนทำงานบนฐานรหัสได้หรือไม่ ดังนั้นถ้าเราต้องแกล้งทำเป็นว่าเราใช้ภาษาที่มีวัตถุประสงค์ทั่วไปเพื่อจ้างคนเราจะ

หากคุณตกลงกับที่แล้วก็ดี แน่นอนคุณไม่ใช่คนเดียว

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

ฉันไม่มีที่ว่างในฐานรหัสสำหรับสิ่งที่ไม่ต้องการ

สำหรับ SOLID และหลักการออกแบบอื่น ๆ ฉันสามารถติดตามสิ่งเหล่านั้นได้แม้ในโดเมนที่เป็นโลหิตจาง การไม่ติดตามพวกเขาทำให้เกิดปัญหาประเภทอื่น