การนำเสนอเลเยอร์แอปพลิเคชัน VS ใน DDD

9

ฉันมีปัญหาในการวาดเส้นที่ชัดเจนระหว่าง Presentation และ Application layer ใน Domain Driven Design

ไฟล์คอนโทรลเลอร์, มุมมอง, เลย์เอาต์, Javascript และ CSS ควรไปที่ใด

มันอยู่ใน Application หรือเลเยอร์การนำเสนอหรือไม่?

และถ้าพวกมันรวมกันในเลเยอร์เดียวกันสิ่งที่มีอีกอันหนึ่ง? มันว่างเปล่า

architecture domain-driven-design layers

7

เพียงเพราะมีคนสร้างและตั้งชื่อว่า "Application Layer" และ "Presentation Layer" ไม่ได้หมายความว่าใบสมัครของคุณควรมี คุณควรสร้างเลเยอร์หลังจากคุณสร้างรหัสจำนวนมากซึ่งคุณจัดกลุ่มเข้าด้วยกันและต้องการตั้งชื่อกลุ่มนี้เพื่อการสื่อสารระหว่างผู้พัฒนาและความชัดเจนของรหัส

จากจุด DDD Application Layer คือทุกสิ่งที่ไม่ใช่ Domain Layer ซึ่งรวมถึงแอปพลิเคชันตรรกะงานนำเสนอและบริการแอปพลิเคชัน

— ร่าเริง
แหล่งที่มา

2

ขอบคุณจริง ๆ แล้วคุณทำให้ฉันรู้ว่าสำหรับกรณีของฉันแยกแอปพลิเคชันและงานนำเสนอนั้นไร้ประโยชน์ ความเรียบง่ายก่อน!

— Matthieu Napoli

หาก DDD มี REST API แทน UI ในเลเยอร์การนำเสนอ REST API จะเป็นแอปพลิเคชันหรือเลเยอร์การนำเสนอ ฉันกำลังสับสนตอนนี้ตั้งแต่ผมแน่ใจว่า REST API เป็นชั้นนำเสนอ ..

— Dario Granich

8

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

— Rogério

11

มีความแตกต่างใหญ่ระหว่างชั้นแอปพลิเคชันและชั้นนำเสนอจากมุมมอง DDD

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

สถาปัตยกรรมมีบทบาทสำคัญในการใช้แอพ DDD ที่ประสบความสำเร็จ สถาปัตยกรรมที่มีชื่อเสียงที่ได้รับการโฆษณามากขึ้นเมื่อเร็ว ๆ นี้คือสถาปัตยกรรมหัวหอม:

ป้อนคำอธิบายรูปภาพที่นี่

ในการออกแบบนี้ชั้น UI / การนำเสนอและชั้นแอปพลิเคชันจะแยกกันอย่างชัดเจน การผสาน 2 เข้าด้วยกันเป็นการแนะนำการมีเพศสัมพันธ์อย่างแน่นหนาระหว่าง 2 เลเยอร์ที่มีข้อกังวลและความรับผิดชอบที่ชัดเจน

เลเยอร์การนำเสนอควรแสดงตรรกะของการนำเสนอเท่านั้น หลีกเลี่ยง Smart UIs ที่รู้มากเกินไป สิ่งนี้เป็นที่ตั้งของตัวควบคุมและมุมมองของ MVC นอกเหนือจาก CSS, JS, แม่แบบฟอร์มและทุกสิ่งที่เกี่ยวข้องกับการตอบสนองและขอวัตถุ

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

ดูตัวอย่างโครงการจากทางไกลต่างประเทศของVaughn Vernon

— Songo
แหล่งที่มา

2

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

— Sinaesthetic

อยู่ที่ไหนentry pointและcomposition rootอยู่ที่ไหน ฉันคิดเสมอว่ามันเป็นความรับผิดชอบของApplicationเลเยอร์ แต่ตอนนี้ดูเหมือนว่านี่คือPresentationเลเยอร์

— Denis535

2

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

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

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

— zafarkhaja
แหล่งที่มา