ในความคิดของฉันมันไม่ได้มีความหมายอย่างแท้จริง และเป็นการละเมิด DRY
แนวคิดคือวัตถุเอนทิตี / โดเมนที่อยู่ตรงกลางถูกสร้างแบบจำลองเพื่อแสดงโดเมนที่ดีและสะดวกที่สุด มันอยู่ในศูนย์กลางของทุกสิ่งและทุกอย่างขึ้นอยู่กับมันเนื่องจากโดเมนจะไม่เปลี่ยนแปลงส่วนใหญ่
หากฐานข้อมูลของคุณอยู่ด้านนอกสามารถจัดเก็บวัตถุเหล่านั้นได้โดยตรงการแมปไปยังรูปแบบอื่นเพื่อการแยกเลเยอร์นั้นไม่เพียง แต่ไร้ประโยชน์เท่านั้น แต่ยังเป็นการสร้างความซ้ำซ้อนของแบบจำลอง
ในการเริ่มต้นสถาปัตยกรรมสะอาดถูกสร้างขึ้นโดยคำนึงถึงสภาพแวดล้อม / สถานการณ์โดยทั่วไปที่แตกต่างกัน แอปพลิเคชันเซิร์ฟเวอร์ธุรกิจที่มีเลเยอร์นอกสุดที่ต้องการวัตถุพิเศษประเภทต่าง ๆ ตัวอย่างเช่นฐานข้อมูลที่ผลิตSQLRowวัตถุและต้องการSQLTransactionsกลับไปปรับปรุงรายการ หากคุณจะใช้สิ่งเหล่านี้ในศูนย์คุณจะต้องฝ่าฝืนทิศทางการพึ่งพาเพราะแกนกลางของคุณจะขึ้นอยู่กับฐานข้อมูล
ด้วยน้ำหนักเบา ORMs ที่โหลดและเก็บวัตถุเอนทิตีที่ไม่ใช่กรณี พวกเขาทำแผนที่ระหว่างภายในSQLRowและโดเมนของคุณ แม้ว่าคุณจะต้องใส่@Entitiyคำอธิบายประกอบของออมลงในวัตถุโดเมนของคุณฉันจะยืนยันว่าสิ่งนี้ไม่ได้สร้าง "กล่าวถึง" ของชั้นนอก เนื่องจากคำอธิบายประกอบเป็นเพียงข้อมูลเมตาไม่มีรหัสที่ไม่ได้ค้นหาโดยเฉพาะพวกเขาจะเห็นพวกเขา และที่สำคัญไม่มีความจำเป็นต้องเปลี่ยนแปลงหากคุณลบออกหรือแทนที่ด้วยคำอธิบายประกอบของฐานข้อมูลอื่น
ในทางตรงกันข้ามถ้าคุณเปลี่ยนโดเมนของคุณและคุณทำสิ่งที่แมปเหล่านั้นทั้งหมดคุณต้องเปลี่ยนมาก
คำแปรญัตติ: ข้างต้นเป็นสิ่งที่เล็กน้อยเกินไปและอาจผิด เนื่องจากมีส่วนหนึ่งในสถาปัตยกรรมแบบคลีนที่ต้องการให้คุณสร้างการแสดงต่อเลเยอร์ แต่นั่นจะต้องเห็นในบริบทของแอปพลิเคชัน
นี่คือที่นี่https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
สิ่งสำคัญคือโครงสร้างข้อมูลที่แยกได้ง่ายถูกส่งผ่านข้ามขอบเขต เราไม่ต้องการโกงและส่งผ่านเอนทิตีหรือแถวฐานข้อมูล เราไม่ต้องการให้โครงสร้างข้อมูลมีการพึ่งพาใด ๆ ที่ละเมิดกฎการพึ่งพา
การส่งเอนทิตีจากจุดศูนย์กลางไปยังเลเยอร์ด้านนอกไม่ได้ละเมิดกฎการพึ่งพา แต่ก็ถูกกล่าวถึง แต่นี่เป็นเหตุผลในบริบทของแอพพลิเคชั่นที่จินตนาการ การส่งเอนทิตีไปรอบ ๆ จะย้ายแอปพลิเคชันตรรกะไปด้านนอก เลเยอร์ด้านนอกจำเป็นต้องรู้วิธีตีความวัตถุภายในพวกมันจะต้องทำในสิ่งที่เลเยอร์ภายในเช่น "กรณีใช้งาน" เลเยอร์ควรจะทำ
นอกจากนั้นมันยังแยกชั้นเพื่อให้การเปลี่ยนแปลงในแกนไม่จำเป็นต้องมีการเปลี่ยนแปลงในชั้นนอก (ดูความคิดเห็นของ SteveCallender) ในบริบทนั้นมันง่ายที่จะเห็นว่าวัตถุควรแสดงถึงวัตถุประสงค์ที่พวกเขาใช้ เลเยอร์นั้นควรพูดคุยกันในแง่ของวัตถุที่ทำขึ้นเป็นพิเศษเพื่อจุดประสงค์ในการสื่อสารนี้ นี่อาจหมายถึงว่ามี 3 การแทน 1 ในแต่ละเลเยอร์ 1 สำหรับการขนส่งระหว่างเลเยอร์
และมีhttps://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Ar Architecture.htmlซึ่งมีที่อยู่ด้านบน:
คนอื่น ๆ กังวลว่าผลลัพธ์สุทธิของคำแนะนำของฉันจะเป็นรหัสซ้ำจำนวนมากและการคัดลอกข้อมูลจำนวนมากจากโครงสร้างข้อมูลหนึ่งไปยังอีกโครงสร้างหนึ่งทั่วทั้งชั้นของระบบ แน่นอนว่าฉันไม่ต้องการสิ่งนี้เช่นกัน และไม่มีสิ่งใดที่ฉันแนะนำจะนำไปสู่การซ้ำซ้อนของโครงสร้างข้อมูลและการคัดลอกฟิลด์ที่ไม่สมบูรณ์
IMO นั้นมีความหมายว่าการคัดลอกวัตถุ 1: 1 เป็นกลิ่นในสถาปัตยกรรมเพราะคุณไม่ได้ใช้เลเยอร์และ / หรือนามธรรมที่เหมาะสม
เขาอธิบายในภายหลังว่าเขาจินตนาการทั้งหมด "คัดลอก"
คุณแยก UI ออกจากกฎทางธุรกิจโดยการส่งผ่านโครงสร้างข้อมูลอย่างง่ายระหว่างทั้งสอง คุณไม่ให้ผู้ควบคุมของคุณรู้อะไรเกี่ยวกับกฎเกณฑ์ทางธุรกิจ แต่ผู้ควบคุมจะแกะวัตถุ HttpRequest ลงในโครงสร้างข้อมูลวานิลลาอย่างง่ายจากนั้นส่งโครงสร้างข้อมูลนั้นไปยังวัตถุที่มีปฏิสัมพันธ์ซึ่งใช้กรณีการใช้งานโดยเรียกใช้วัตถุทางธุรกิจ จากนั้นผู้โต้ตอบจะรวบรวมข้อมูลการตอบกลับไปยังโครงสร้างข้อมูลวานิลลาอื่นและส่งกลับไปยัง UI มุมมองไม่ทราบเกี่ยวกับวัตถุธุรกิจ พวกเขาแค่ดูในโครงสร้างข้อมูลนั้นและนำเสนอการตอบสนอง
ในแอปพลิเคชั่นนี้มีความแตกต่างอย่างมากระหว่างการเป็นตัวแทน ข้อมูลที่ไหลไม่ได้เป็นเพียงเอนทิตี และสิ่งนี้รับประกันและต้องการชั้นเรียนที่แตกต่างกัน
อย่างไรก็ตามนำไปใช้กับแอปพลิเคชัน Android อย่างง่ายเช่นโปรแกรมดูรูปภาพที่Photoมีกฎทางธุรกิจเกี่ยวกับ 0 และ "กรณีการใช้งาน" ที่เกี่ยวข้องกับพวกเขาเกือบจะไม่มีอยู่จริงและมีความกังวลมากขึ้นเกี่ยวกับการแคชและดาวน์โหลด แทนอย่างชัดเจนมากขึ้น) จุดที่จะทำให้การแสดงรูปภาพแยกกันหายไป ฉันยังรู้สึกว่ารูปถ่ายนั้นเป็นวัตถุการถ่ายโอนข้อมูลในขณะที่ชั้นตรรกะทางธุรกิจหลักที่แท้จริงหายไป
มีความแตกต่างระหว่างการเป็น"แยก UI จากกฎเกณฑ์ทางธุรกิจโดยผ่านโครงสร้างข้อมูลง่ายระหว่างสอง"และ"เมื่อคุณต้องการแสดงรูปภาพเปลี่ยนชื่อเป็นครั้งที่ 3 ในทาง"
นอกจากนั้นจุดที่ฉันเห็นแอปพลิเคชันสาธิตเหล่านั้นล้มเหลวในการแสดงถึงสถาปัตยกรรมแบบคลีนคือพวกเขาเพิ่มความสำคัญอย่างมากในการแยกเลเยอร์เพื่อแยกเลเยอร์ แต่ซ่อนสิ่งที่แอปพลิเคชันทำได้อย่างมีประสิทธิภาพ ซึ่งตรงกันข้ามกับที่กล่าวไว้ในhttps://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Ar Architecture.html - กล่าวคือ
สถาปัตยกรรมของแอปพลิเคชันซอฟต์แวร์กรีดร้องเกี่ยวกับกรณีการใช้งานของแอปพลิเคชัน
ฉันไม่เห็นความสำคัญในการแยกเลเยอร์ในสถาปัตยกรรมที่สะอาด มันเกี่ยวกับทิศทางการพึ่งพาอาศัยกันและมุ่งเน้นไปที่การเป็นแกนหลักของแอปพลิเคชัน - เอนทิตีและกรณีการใช้งาน - ใน java ธรรมดา ๆ โดยไม่ต้องพึ่งพาภายนอก มันไม่ได้เกี่ยวกับการพึ่งพาแกนกลางนั้นมากนัก
ดังนั้นหากแอปพลิเคชันของคุณมีแกนหลักที่แสดงถึงกฎเกณฑ์ทางธุรกิจและกรณีการใช้งานและ / หรือคนอื่นทำงานในเลเยอร์ที่แตกต่างกันโปรดแยกพวกเขาออกตามวิธีที่ตั้งใจไว้ หากคุณเพียงแค่เขียนแอพที่เรียบง่ายด้วยตัวเองอย่าหักโหมจนเกินไป 2 ชั้นที่มีขอบเขตคล่องแคล่วอาจเกินพอ และเลเยอร์สามารถเพิ่มในภายหลังได้เช่นกัน
BankAccountแต่มีกฎเฉพาะแอปพลิเคชันที่คุณสามารถทำได้กับบัญชีนั้น