"สถาปัตยกรรมสะอาด" โดยบ็อบมาร์ตินเป็นกฎง่ายๆสำหรับสถาปัตยกรรมทั้งหมดหรือเป็นเพียงหนึ่งในตัวเลือกหรือไม่?

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

นี่เป็นวิธีหนึ่งในการเขียนโปรแกรมที่ดี แต่ไม่ใช่วิธีเดียว

Rails และ reactjs เป็น 2 เฟรมเวิร์กที่มาพร้อมกับจิตใจที่ไม่สนับสนุนสถาปัตยกรรมที่สะอาดเช่นนี้ Rails คาดว่าตรรกะทางธุรกิจของคุณจะอยู่ในรูปแบบ ( FatModels และ SkinnyControllers ) และตอบสนองภายในองค์ประกอบของคุณ ทั้งสองวิธีทั้งคู่แน่นตรรกะทางธุรกิจและรหัสกรอบ

ฉันไม่พบสิ่งผิดปกติใน 3 วิธี มันเป็นการตัดสินใจที่จะเลือกใคร

แต่ในวิดีโอฉันรู้สึกว่าเขาแนะนำว่าสถาปัตยกรรมสะอาดควรมีขอบเขตที่ชัดเจนระหว่างตรรกะทางธุรกิจและกรอบงาน Frameworks (เว็บแอนดรอยด์ ฯลฯ ) ควรเป็นปลั๊กอินที่เชื่อมต่อกับตรรกะทางธุรกิจ เขายังแยกรางรถไฟในวิดีโออย่างละเอียด

ดังนั้น"Clean Architecture" โดย Bob Martin เป็นกฎง่ายๆสำหรับสถาปัตยกรรมทั้งหมดหรือเป็นเพียงหนึ่งในตัวเลือกหรือไม่

ในขณะที่ "สถาปัตยกรรมสะอาด" ดีและมีข้อดีหลายประการสิ่งสำคัญคือต้องจำไว้ว่า:

• สถาปัตยกรรมสะอาดเป็นส่วนใหญ่ของโรเบิร์ตซีมาร์ตินการสร้างตราสินค้าใหม่และวิวัฒนาการของวิธีการที่เกี่ยวข้องเช่นสถาปัตยกรรมหัวหอมโดยเจฟฟรีย์ปาแลร์โม (2008) และสถาปัตยกรรมหกเหลี่ยม ("พอร์ตและอะแดปเตอร์") โดย Alistair Cockburn และอื่น ๆ

• ปัญหาที่แตกต่างกันมีข้อกำหนดที่แตกต่างกัน สถาปัตยกรรมที่สะอาดและวิธีการที่เกี่ยวข้องเปลี่ยนการแยกความยืดหยุ่นและการพึ่งพาอาศัยกันเป็นสิบเอ็ด แต่เสียสละความเรียบง่าย นี่ไม่ใช่ข้อตกลงที่ดีเสมอไป

บรรพบุรุษของสถาปัตยกรรมเหล่านี้เป็นรูปแบบ MVC คลาสสิกจาก Smalltalk สิ่งนี้จะยกเลิกโมเดลจากส่วนต่อประสานผู้ใช้ (คอนโทรลเลอร์และมุมมอง) เพื่อให้โมเดลไม่ได้ขึ้นอยู่กับ UI MVC มีหลากหลายรูปแบบเช่น MVP, MVVM, ...

ระบบที่ซับซ้อนมากขึ้นไม่มีส่วนต่อประสานผู้ใช้เพียงส่วนเดียว แต่อาจมีส่วนต่อประสานกับผู้ใช้หลายคน แอพจำนวนมากเลือกที่จะเสนอ REST API ที่ UI สามารถใช้งานได้เช่นเว็บแอพหรือแอพมือถือ สิ่งนี้แยกตรรกะทางธุรกิจบนเซิร์ฟเวอร์จาก UIs เหล่านี้ดังนั้นเซิร์ฟเวอร์จึงไม่สนใจว่าแอปประเภทใดที่เข้าถึง

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

สถาปัตยกรรมแบบหกเหลี่ยมดำเนินต่อไปและหยุดสร้างความแตกต่างระหว่างส่วนหน้าและส่วนหลัง ระบบภายนอกใด ๆ อาจเป็นอินพุต (แหล่งข้อมูล) หรือเอาต์พุต ระบบหลักของเรากำหนดอินเทอร์เฟซที่จำเป็น (พอร์ต) และเราสร้างอะแดปเตอร์สำหรับระบบภายนอก

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

วิธีการทั้งหมดนี้มีข้อดีเช่นทำให้การทดสอบระบบแยกง่ายขึ้น(โดยแทนที่ระบบภายนอกทั้งหมดที่เชื่อมต่อด้วยโดยการใช้งานจำลอง) ช่วยให้การปรับใช้หลายครั้งง่ายขึ้นสำหรับบริการประเภทหนึ่ง (เช่นการเพิ่มหน่วยประมวลผลการชำระเงินที่สอง) หรือเปลี่ยนการใช้งานบริการ (เช่นการย้ายจากฐานข้อมูล Oracle ไปยัง PostgreSQL หรือเขียนบริการ Python ใหม่ใน Go) .

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

กรอบการทำงานทำให้สมมติฐานเกี่ยวกับสิ่งที่กำลังจะเปลี่ยน เช่นปฏิกิริยามีแนวโน้มที่จะถือว่าการออกแบบและพฤติกรรมของส่วนประกอบเปลี่ยนไปด้วยกันดังนั้นจึงไม่มีความเหมาะสมที่จะแยกพวกมันออก เฟรมเวิร์กน้อยสมมติว่าคุณอาจต้องการเปลี่ยนเฟรมเวิร์ก ดังนั้นเฟรมเวิร์กจะแสดงจำนวนการล็อกอิน เช่นการพึ่งพา Rail (รูปแบบการให้ความเห็นอย่างมาก!) รูปแบบการบันทึกที่ใช้งานอยู่ทำให้ยากที่จะเป็นไปไม่ได้ที่จะเปลี่ยนกลยุทธ์การเข้าถึงข้อมูลของคุณเป็นรูปแบบพื้นที่เก็บข้อมูล (มักจะเหนือกว่า) หากความคาดหวังของการเปลี่ยนแปลงของคุณไม่ตรงกับกรอบการใช้กรอบงานที่แตกต่างกันอาจจะดีกว่า กรอบงานเว็บอื่น ๆ อีกมากมายไม่ได้ตั้งสมมติฐานเกี่ยวกับการเข้าถึงข้อมูล

ฉันชอบแนวคิดในวิดีโอ The Principles of Clean Architecture โดยลุง Bob Martin แต่ฉันรู้สึกว่ารูปแบบนี้เหมือนกับการรวมกันของรูปแบบนามธรรมจากโรงงานและตัวสร้างที่แกนกลางของมัน

ไม่ได้ใกล้เคียง.

เมื่อคุณดูสิ่งนี้:

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

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

ที่จริงแล้วฉันสามารถสร้างทุกสิ่งที่คุณเห็นในแผนภาพนั้นเป็นหลัก จากนั้นเพียงเรียกวิธีการหนึ่งในวัตถุหนึ่งเพื่อเริ่มต้นการฟ้องร้องทั้งหมด

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

main()และคุณสามารถสร้างทุกที่โดยไม่ต้องออก

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

"สถาปัตยกรรมสะอาด" โดยบ็อบมาร์ตินเป็นกฎง่ายๆสำหรับสถาปัตยกรรมทั้งหมดหรือเป็นเพียงหนึ่งในตัวเลือกหรือไม่?

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

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

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

ไม่ว่าสิ่งที่น่ากลัวจะมีบริบทที่คุณสามารถใส่ไว้ในนั้นจะทำให้ไร้สาระ ขออภัยนี่ไม่ใช่ bullet เงิน

แต่ในวิดีโอฉันรู้สึกว่าเขาแนะนำว่าสถาปัตยกรรมสะอาดควรมีขอบเขตที่ชัดเจนระหว่างตรรกะทางธุรกิจและกรอบงาน Frameworks (เว็บแอนดรอยด์ ฯลฯ ) ควรเป็นปลั๊กอินที่เชื่อมต่อกับตรรกะทางธุรกิจ เขายังแยกรางรถไฟในวิดีโออย่างละเอียด

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

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

ตราบใดที่ความต้องการของคุณได้รับการคาดหวังจากกรอบงานสิ่งต่าง ๆ จะราบรื่นมาก ยินดีที่ได้รับความคาดหวังจากคุณ มันทำให้คุณอยู่ในกล่องที่ทำให้สิ่งต่าง ๆ ง่ายขึ้น แค่เข้าใจสิ่งที่คุณยอมแพ้เพื่อรับสิ่งนี้ หากคุณกระจาย Spring ทุกที่คุณจะไม่สามารถโฆษณาได้ว่าเป็นงาน Java อีกต่อไป มันเป็นงาน Java / Spring ฉันสามารถพูดในสิ่งเดียวกันเกี่ยวกับ Ruby and Rails ได้ แต่ Rails กิน Ruby's lunch มานานแล้ว

หากต้องการอ้างถึงวิดีโอ:

"คุณไม่ต้องการรวมเมลใน SQL"

ติดตามโดย:

"ฉันเห็นกระบวนการจัดเก็บ SQL ซึ่งเป็นจดหมายเวียนทั้งหมด"

สถาปัตยกรรมเช่นเดียวกับการรวมจดหมายเป็นเพียงตัวเลือกเดียวในหลาย ๆ

สิ่งที่ไม่ได้เลือกคือปัญหาที่สถาปัตยกรรมพยายามแก้ไข

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

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

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

นี่คือการวิเคราะห์แบบประโยคต่อประโยคของบทความของลุงบ็อบเกี่ยวกับสถาปัตยกรรมสะอาดด้วยเหตุผลของข้อความข้างต้น:

สถาปัตยกรรมที่สะอาดจากมุมมองเชิงวัตถุ

สถาปัตยกรรมสะอาดเป็นชุดของหลักการและรูปแบบเพื่อจัดการกับอาการที่พบบ่อยขององค์กรพัฒนาซอฟต์แวร์ที่มักจะเผชิญกับช่วงเวลาของการสร้างแอพพลิเคชั่นที่ซับซ้อน มิสเตอร์มาร์ตินพยายามอย่างสุดความสามารถในหนังสือเล่มนี้เพื่อระบุอาการและสาเหตุที่เป็นรากฐานจากประสบการณ์ที่กว้างขวางของเขาในสาขานี้และเพื่ออธิบายบทบาทของสถาปัตยกรรมในการบรรเทาความกังวลเหล่านี้

อย่างไรก็ตามมันไม่ใช่ Rule of Thumb หรือยาครอบจักรวาลสำหรับความเจ็บป่วยทั้งหมด ถ้าคุณอ่านหนังสือคุณจะมีความเข้าใจที่ดีขึ้นว่า / เมื่อ / วิธีการใช้หลักการและรูปแบบที่เขาสนับสนุน (และการแลกเปลี่ยนที่เกี่ยวข้อง) หากคุณยังไม่ได้อ่านหนังสือคุณมีแนวโน้มที่จะใช้สมมติฐานการใช้งานคำพิพากษาและข้อความที่ไม่ถูกต้องตามข้อมูลที่ไม่สมบูรณ์