นักพัฒนา Rails คนหนึ่งได้จุดประกายการอย่างในชุมชนด้วยการวิเคราะห์อย่างวิพากษ์วิจารณ์ต่อรูปแบบ Hexagonal Architecture ที่ได้รับความนิยมในแอปพลิเคชัน Rails เมื่อประมาณหนึ่งทศวรรษที่แล้ว ผู้เขียนได้คิดคำศัพท์ใหม่ว่า hexatetrahedral Rails เพื่อบรรยายแอปพลิเคชันที่เติบโตจนซับซ้อนเกินไปผ่านแนวทางสถาปัตยกรรมนี้ โดยตั้งคำถามว่าผลประโยชน์ที่ได้รับนั้นคุ้มค่ากับความซับซ้อนที่เพิ่มขึ้นหรือไม่
ช่องว่างระหว่างสิ่งที่สัญญาไว้กับความเป็นจริง
Hexagonal Architecture เดิมที่เสนอโดย Dr. Alistair Cockburn มีเป้าหมายเพื่อสร้างการแยกที่ชัดเจนระหว่างตรรกะทางธุรกิจกับข้อกังวลภายนอกผ่านอินเทอร์เฟซที่กำหนดไว้อย่างชัดเจน อย่างไรก็ตาม การนำไปใช้งานใน Rails หลายๆ แบบได้หลุดออกไปไกลจากวิสัยทัศน์นี้ แทนที่จะบรรลุความเป็นโมดูลาร์ที่ตั้งใจไว้ แอปพลิเคชันเหล่านี้มักกลายเป็นฝันร้ายในการบำรุงรักษาที่เต็มไปด้วยการทำนามธรรมที่ไม่จำเป็นและเครื่องมือที่ไม่เป็นมาตรฐาน
ชุมชนได้สังเกตว่าแม้ repositories จะสามารถป้องกันนักพัฒนาระดับเริ่มต้นจากการทำผิดพลาดที่มีราคาแพงกับฐานข้อมูลได้ แต่การสร้างมันบนฐาน ActiveRecord แทนที่จะแทนที่มันทั้งหมดนั้นสมเหตุสมผลมากกว่า แนวทางนี้รักษาธรรมเนียมของ Rails ไว้ในขณะที่เพิ่มการป้องกันที่จำเป็น
ลักษณะทั่วไปของแอป Rails แบบ "Hexatetrahedral":
- ใช้ DataMapper หรือ ROM แทน ActiveRecord
- ใช้ไลบรารี dry-rb อย่างหนัก
- ใช้ RSpec พร้อมกับ mocking อย่างละเอียดแทน Minitest
- ใช้ FactoryBot แทน fixtures
- ใช้รูปแบบ Repository ที่ห่อหุ้มการเข้าถึง ActiveRecord
- ใช้ Trailblazer และ ROM สำหรับ views
- ใช้ Service objects สำหรับ business logic
ภาระการบำรุงรักษาและพลวัตของทีม
ข้อกังวลสำคัญที่ถูกยกขึ้นคือภาระการบำรุงรักษาของแอปพลิเคชัน hexatetrahedral โค้ดเบสเหล่านี้มักพึ่งพาไลบรารีจากบุคคลที่สามจำนวนมากและการทำนามธรรมแบบกำหนดเองที่ต้องการการอัปเดตอย่างต่อเนื่องและความเข้าใจอย่างลึกซึ้ง เมื่อสมาชิกในทีมลาออกหรือไลบรารีล้าสมัย ภาระความรู้จะตกอยู่กับนักพัฒนาที่เหลืออยู่อย่างหนัก
การอย่างนี้เผยให้เห็นปัญหาที่ทีมพัฒนาต้องเผชิญอย่างทั่วไป: การเลือกระหว่างรูปแบบ Rails ที่มีเอกสารครบถ้วนและใช้กันอย่างแพร่หลาย กับการบำรุงรักษาการตัดสินใจทางสถาปัตยกรรมแบบกำหนดเองที่ทำไว้เมื่อหลายปีก่อน นักพัฒนาส่วนใหญ่เมื่อถูกกดดันด้วยเวลาจะละทิ้งแนวทางแบบกำหนดเองเพื่อใช้วิธีการมาตรฐานของ Rails
ปัญหาการจำกัด API
ผู้เขียนระบุสิ่งที่เขาเชื่อว่าเป็นแรงจูงใจที่แท้จริงเบื้องหลังสถาปัตยกรรม hexagonal Rails: การลดพื้นผิว API ขนาดใหญ่ของ ActiveRecord ด้วยเมธอดคลาสกว่า 666 เมธอดและเมธอดอินสแตนซ์ 230 เมธอดที่มีอยู่ใน ApplicationRecord พื้นฐาน การควบคุมวิธีที่ทีมโต้ตอบกับข้อมูลจึงกลายเป็นเรื่องท้าทายในองค์กรขนาดใหญ่
หากอินเทอร์เฟซของฉันเป็น ActiveRecord ดิบ คุณก็ไม่สามารถโกรธนักพัฒนาระดับเริ่มต้นของคุณได้ที่ทำการสแกนตารางทั้งหมดด้วย 'where' ในทุกคำขอ
ข้อมูลเชิงลึกนี้สะท้อนกับนักพัฒนาที่เคยประสบกับความเจ็บปวดจากการเข้าถึงฐานข้อมูลแบบไม่จำกัดในแอปพลิเคชันที่กำลังเติบโต
ความซับซ้อนของ API ของ ActiveRecord:
- มี class methods ที่ใช้งานได้ 666 ตัวบน ApplicationRecord
- มี instance methods 230 ตัวต่อโมเดล
- ทุก association จะเปิดเผย method จำนวนเท่ากันบวกกับ association helpers
- พฤติกรรมของ method ที่ซับซ้อนพร้อมข้อจำกัดในการเรียงลำดับและการพึ่งพาอาศัยกัน
ทางเลือกที่เรียบง่ายกว่า
แทนที่จะนำ hexagonal architecture แบบเต็มรูปแบบมาใช้ ผู้เขียนแนะนำแนวทางที่ปฏิบัติได้มากกว่าโดยใช้ Ruby modules เพื่อจัดระเบียบตรรกะโดเมน วิธีนี้ให้การแยก namespace และขอบเขตที่ชัดเจนกว่าโดยไม่มีภาระความซับซ้อนของ repositories, service objects และ ORM แบบกำหนดเองที่เป็นลักษณะเฉพาะของแอปพลิเคชัน hexatetrahedral
ชุมชน Rails ดูเหมือนจะก้าวข้ามแฟชั่นทางสถาปัตยกรรมนี้ไปแล้ว โดยมีโซลูชันใหม่ๆ เช่น Packwerk ที่จัดการกับข้อกังวลที่คล้ายกันเกี่ยวกับการจัดระเบียบโค้ดและขอบเขตของทีม ฉันทามติดูเหมือนจะโน้มเอียงไปทางวินัยและธรรมเนียมที่ชัดเจนมากกว่าความซับซ้อนทางสถาปัตยกรรม โดยเฉพาะอย่างยิ่งเมื่อพิจารณาว่าแอปพลิเคชันส่วนใหญ่ไม่ต้องการผลประโยชน์ในทางทฤษฎีที่ hexagonal architecture สัญญาว่าจะส่งมอบให้
หมายเหตุ: Hexatetrahedral หมายถึงรูปทรงเรขาคณิตที่ซับซ้อน ใช้ในที่นี้เป็นคำอุปมาเพื่อบรรยายรูปแบบสถาปัตยกรรมที่ซับซ้อนเกินไป
อ้างอิง: Hexatetrahedral Rails