สถาปัตยกรรม (โครงสร้าง) - มุ่งเน้นกับโครงสร้างโครงการที่มุ่งเน้นคุณสมบัติ

ฉันมีส่วนเกี่ยวข้องกับโครงการมีโครงสร้างไฟล์ / โฟลเดอร์ของโครงการที่มุ่งเน้นสถาปัตยกรรม:

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

มันชัดเจนจากมุมมองทางสถาปัตยกรรมของระบบ (ได้รับการเสนอโดยทีมพัฒนา)

มันเป็นโครงสร้างที่มุ่งเน้นคุณสมบัติที่ได้รับการเสนอโดยทีมนักออกแบบ:

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

ตัวแปรนี้อยู่ใกล้กับผู้ออกแบบและอธิบายคุณลักษณะที่จะนำไปใช้อย่างชัดเจน

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

ขอขอบคุณ.

ฉันจะลงคะแนนให้คนที่สอง ในโครงสร้างครั้งแรก, รถขนเหตุการณ์จะสมบูรณ์ไม่เกี่ยวข้องกับการจัดการเหตุการณ์สำหรับFeatureA FeatureBดูเหมือนว่านักพัฒนาซอฟต์แวร์จะทำงานบนฟีเจอร์หนึ่งครั้งและหากคุณกำลังดำเนินการFeatureXตามคำขออาจเป็นไปได้ว่าคุณจะต้องปรับแต่งตัวFeatureXจัดการการร้องขอมากกว่าพูดFeatureZคำขอ

โดยวิธีการที่ฉันรักวิธีที่คุณถามคำถามนี้จากมุมมองที่เป็นกลาง

ฉันรู้สึกสะดวกสบายกับวิธีที่สองเสมอ แต่ฉันมักจะมี "คุณสมบัติ" ที่เรียกว่าทั่วไปหรือทั่วไปสำหรับคลาสที่แชร์ / ฐานอย่างแท้จริง

แนวทางที่สองช่วยแยกสิ่งต่าง ๆ อย่างแท้จริง แต่หากไม่มีพื้นที่ "ทั่วไป" บางครั้งก็แยกสิ่งต่าง ๆ ออกเป็นส่วน ๆ ที่ไม่เหมาะสม

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

นี่เป็นปัญหาที่สำคัญอย่างยิ่งเมื่อการใช้งานของคุณสมบัติครอบคลุมหลาย dll, exes, ฐานข้อมูลหรือชิ้นส่วนซอฟต์แวร์อื่น ๆ

ต้องเห็นด้วยกับวิธีที่สองให้ทั้งสองตัวเลือก คนแรกดูเหมือนหยดอสัณฐาน อย่างน้อยรูปที่สองมีรูปร่างบ้าง

มันขึ้นอยู่กับว่าโครงการใหญ่แค่ไหน หาก "คุณสมบัติ" มีขนาดใหญ่พวกเขาแต่ละคนต้องมีที่เก็บข้อมูลที่แตกต่างกัน

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

นอกจากว่าคุณจะมีฟีเจอร์เพียงหยิบมือเดียวคุณจำเป็นต้องจัดกลุ่มไว้ในหมวดหมู่ - และมันไม่ได้ถูกออกแบบมาให้รองรับ (ยกเว้นว่าเป็นสิ่งที่ Node1 ตั้งใจไว้ แต่แนะนำ "X ทั้งหมด" ของโครงการ) เป็นอย่างอื่นและทำให้ฉันสงสัยว่ามันเป็น WTF - มี Node2 หรือไม่?)

ฉันอาจพิจารณาบางสิ่งเช่นนี้:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

หรือสิ่งนี้:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events

แต่พวกเขาทั้งคู่กำลังตั้งสมมติฐานซึ่งอาจไม่สมบูรณ์ถ้าคุณสามารถอัปเดตคำถามของคุณพร้อมรายละเอียดเพิ่มเติมฉันอาจเปลี่ยนใจ :)