มีกลิ่นสถาปัตยกรรมหรือไม่?

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

แก้ไข:ฉันไม่ได้มองหารายการในคำตอบ แต่เอกสาร (บนเว็บหรือในหนังสือ) เกี่ยวกับกลิ่นสถาปัตยกรรม

• สถาปัตยกรรมแบบหลายเทียร์ เมื่อคุณมีเลเยอร์บนเลเยอร์บนเลเยอร์บนเลเยอร์ ... คุณเห็นจุดของฉันที่นี่ในใบสมัครของคุณ ฉันเรียกมันว่าOver Layered Architecture
• เหนือสิ่งที่เป็นนามธรรมในแบบที่คุณหลงทางในรหัส
• สถาปัตยกรรมแห่งอนาคตสิ่งนี้เกิดขึ้นเมื่อวิธีแก้ปัญหาเป็นอนาคตเกินไป ในความเป็นจริงไม่มีใครสามารถทำนายข้อกำหนดใหม่ได้ ดังนั้นการใช้งานอนาคตส่วนใหญ่เป็นเพียงการเสียเวลาและทรัพยากร
• Technology Enthusiastic Architecture สถาปนิกชอบเทคโนโลยีใหม่และเขาผลิต โดยไม่รู้ว่ามันได้รับการพิสูจน์มาก่อน
• Over Kill Architectureปัญหาง่าย ๆ ได้รับการแก้ไขโดยปัจจัยด้านทักษะสถาปัตยกรรมและเทคโนโลยี
• สถาปัตยกรรมคลาวด์ ฉันเรียกมันว่าสถาปัตยกรรมคลาวด์เนื่องจากสถาปัตยกรรมไม่มีการเชื่อมต่อกับจริง ๆ มันเป็นเพียงไดอะแกรม Visio ที่ดี

การขาดสิ่งที่ตรงกันข้ามทั้งหมดก็เป็นจริงเช่นกัน

นี่คือการเชื่อมโยงของข้อผิดพลาด Top Ten สถาปัตยกรรมซอฟต์แวร์

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

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

และจากนั้นคุณก็ตกอยู่ในอันตรายของซอฟต์แวร์

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

กลิ่นรหัสและกลิ่นสถาปัตยกรรมเป็นหนึ่งเดียวกัน รหัสเริ่มที่จะ "ดม" เนื่องจากสถาปัตยกรรมย่อยที่ดีที่สุด

ในหนังสือน้ำเชื้อของมาร์ตินฟาวเลอร์ในหัวข้อRefactoringเขานำเสนอชุดของ Code Smells และระบุวิธีในการ refactor พวกเขาออกจากระบบของคุณ Joshua Kerievsky's Refactoring to Patternsให้ความสำคัญกับความคิดนี้มากขึ้นโดยให้รูปแบบสถาปัตยกรรมเฉพาะเพื่อแก้ไขกลิ่นรหัสต่าง ๆ (และวิธีการปรับโครงสร้างเหล่านั้นทีละขั้นตอน)

refactoring ส่วนใหญ่จะทำเพื่อบรรเทารหัสย่อยโดยผ่านสถาปัตยกรรมที่ปรับปรุง เราสามารถโต้แย้งได้ว่า "กลิ่นทางสถาปัตยกรรม" ที่เกิดขึ้นเองตามธรรมชาติ (นอกเหนือจาก Big Ball of Mud) ที่เกิดขึ้นตามธรรมชาตินั้นจะเป็นสถาปัตยกรรม BDUF (การออกแบบขนาดใหญ่ที่อยู่ด้านหน้า) ที่ที่คุณพยายามรองรับทุกสิ่งที่คุณต้องการก่อนที่จะเขียนโค้ดบรรทัดแรก โครงการซอฟต์แวร์แบบว่องไวที่ออกแบบเสร็จตามต้องการ (แม้ฉันกล้าที่จะถือว่าโค้ดเป็นแบบออกแบบ ) ก็จะทำให้สถาปัตยกรรมนั้นเติบโตอย่างเป็นธรรมชาติ

(จำนวนมาก) Coupling -in สิ่ง form- เป็นสิ่งที่ทำให้สถาปัตยกรรมกลิ่น ยิ่งมีคู่มากก็จะมีกลิ่นมากขึ้น

ที่กล่าวว่า: ไม่มีการแต่งงานกันเลยมักจะมีปัญหาเรื่องประสิทธิภาพ

ต่อไปนี้เป็นสถาปัตยกรรมคอนกรีต / การออกแบบกลิ่นที่ฉันพบตลอดเวลา: การวิเคราะห์และการรายงานโดยตรงจากฐานข้อมูลธุรกรรม

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

โดยทั่วไปจะเห็นได้ในแอป Enterprise LOB ซึ่งคือ btw ฉันเข้าใจว่า SMB จำนวนมากไม่มีทรัพยากรหรือความรู้ในการสร้างคลังสินค้าและชุดข้อมูล (ลืมเกี่ยวกับคิวบ์หรือการตั้งค่าการลดแผนที่) แต่องค์กรที่ใหญ่กว่าที่ฉันเคยทำงานด้วยมีปัญหาเดียวกัน

เมื่อออกแบบระบบสถาปนิกควรทราบด้วยว่าการรายงานโดยเฉพาะอย่างยิ่งรายงานการวิเคราะห์และความต้องการด้านการทำธุรกรรมนั้นได้รับการปฏิบัติที่ดีที่สุดเป็นประเด็นแยกต่างหาก

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

มีกลิ่นสถาปัตยกรรมมากมายที่บันทึกโดยชุมชน ชุดที่เกิดขึ้นโดยทั่วไปมีดังต่อไปนี้

• Cyclic Dependency:กลิ่นนี้เกิดขึ้นเมื่อส่วนประกอบสถาปัตยกรรมตั้งแต่สองชิ้นขึ้นไปขึ้นอยู่กับกันและกันโดยตรงหรือโดยอ้อม
• Unstable Dependency:กลิ่นนี้เกิดขึ้นเมื่อส่วนประกอบขึ้นอยู่กับส่วนประกอบอื่น ๆ ที่มีความเสถียรน้อยกว่าตัวมันเอง
• พระเจ้าองค์ประกอบ:กลิ่นนี้เกิดขึ้นเมื่อองค์ประกอบมีขนาดใหญ่เกินไปทั้งในแง่ของ LOC หรือจำนวนชั้นเรียน
• ความเข้มข้นของคุณสมบัติ:กลิ่นนี้เกิดขึ้นเมื่อส่วนประกอบตระหนักถึงความกังวล / คุณสมบัติของสถาปัตยกรรมมากกว่าหนึ่งรายการ
• ฟังก์ชั่นที่กระจัดกระจาย:กลิ่นนี้เกิดขึ้นเมื่อส่วนประกอบหลายอย่างมีความรับผิดชอบในการตระหนักถึงความกังวลระดับสูงเดียวกัน
• โครงสร้างหนาแน่น:กลิ่นนี้เกิดขึ้นเมื่อส่วนประกอบมีการพึ่งพาที่มากเกินไปและหนาแน่นโดยไม่มีโครงสร้างใดเป็นพิเศษ

ฉันเพิ่งจัดทำอนุกรมวิธานของกลิ่น ปัจจุบันมีเอกสาร 38 สถาปัตยกรรมกลิ่นและมากกว่า 260 รหัสรวมกลิ่น