ฉันจะหยุดการออกแบบและเริ่มสร้างโครงการนี้ตามที่แนะนำโดยลูกค้าเป้าหมายของฉันได้อย่างไร [ปิด]

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

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

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

ฉันจะออกจากโหมดผู้ออกแบบซอฟต์แวร์และเริ่มคิดเหมือนสถาปนิกได้อย่างไร

ต่อไปนี้เป็นตัวอย่างของ "การออกแบบ" ที่ฉันเห็นว่าไม่เกี่ยวข้องกับสถาปัตยกรรมโดยผู้นำของฉัน:

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

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

นี่คือรายละเอียดเฉพาะเพิ่มเติมเกี่ยวกับโครงการ :

• โครงการที่เราออกแบบคือเว็บแอปพลิเคชั่น
• ฉันประมาณรหัสประมาณ 10,000 บรรทัด
• เราเริ่มแล้ว ทีมวิศวกรของเราประมาณ 3-5 คน
• สิ่งที่ใกล้เคียงที่สุดที่ฉันสามารถเปรียบเทียบใบสมัครของเราคือ CMS ที่มีน้ำหนักเบา มันมีความซับซ้อนและข้อตกลงคล้ายกันส่วนใหญ่กับการโหลดและการขนถ่ายส่วนประกอบการจัดการเลย์เอาต์และโมดูลสไตล์ปลั๊กอิน
• แอปพลิเคชันคือ Ajax-y ผู้ใช้ดาวน์โหลดไคลเอ็นต์หนึ่งครั้งจากนั้นร้องขอข้อมูลตามที่ต้องการจากเซิร์ฟเวอร์
• เราจะใช้รูปแบบ MVC
• แอปพลิเคชันจะมีการตรวจสอบสิทธิ์
• เราไม่ได้กังวลมากเกี่ยวกับการสนับสนุนเบราว์เซอร์เก่า (ว้าว!) ดังนั้นเราจึงต้องการใช้ประโยชน์จากสิ่งที่ใหม่ที่สุดและยิ่งใหญ่ที่สุดที่มีอยู่และจะออกมา (HTML5, CSS3, WebGL?, ส่วนขยายแหล่งที่มาของสื่อและอื่น ๆ !)

นี่คือเป้าหมายบางส่วนของโครงการ :

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

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

ต้องบอกว่าคุณต้องการคำแนะนำสำหรับสถานการณ์ที่คุณอยู่มีโลกทั้งโลกของสถาปัตยกรรมซอฟต์แวร์ที่นั่นเอกสารหนังสือการประชุม แต่คุณมักจะมองหารูปแบบและนามธรรม หากไม่มีรายละเอียดเพิ่มเติมเกี่ยวกับโครงการฉันสามารถยกตัวอย่างได้อย่างกว้าง ๆ เท่านั้น ตัวอย่างเช่นหากคุณกำลังทำงานในการรวมจะมี Service Oriented Architecture ( SOA)) รูปแบบที่คุณแบ่งส่วนของระบบเป็น 'บริการ' เพื่อให้คุณสามารถทำงานกับแต่ละส่วนในวิธีที่กำหนดไว้ในโปรแกรมเว็บนี้มักจะถูกนำมาใช้เป็นบริการบนเว็บ (แม้ว่าจะไม่ควร จำกัด เพียงเท่านั้น) และเมื่อไม่นานมานี้การเพิ่มขึ้นของ RESTful APIs ด้วย JSON อีกครั้งฉันจะบอกว่านี่เป็นการออกแบบที่มาจากสถาปัตยกรรมของ SOA ฉันจะบอกว่า Model, View, Controller (MVC) เป็นอีกตัวอย่างหนึ่งของรูปแบบสถาปัตยกรรมในการใช้งานทั่วไปโดยแยกความรับผิดชอบของส่วนประกอบของระบบเพื่อให้สามารถสลับชิ้นส่วนได้เพื่อให้มีข้อผิดพลาดและการทดสอบ

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

ฉันยอมรับว่าทั้งสองตัวอย่างที่คุณมอบให้คือการออกแบบโค้ดไม่ใช่สถาปัตยกรรม ครั้งแรกเพราะฉันคิดว่าเมื่อคุณบอกว่าคุณมาพร้อมกับ 'อัลกอริทึม' สำหรับการโหลดทรัพยากรฉันคิดว่าคุณหมายถึงคุณออกแบบชุดคำสั่งเพื่อทำงานให้สำเร็จและไม่ใช่ว่าคุณออกแบบอัลกอริทึมใหม่ที่พวกเขาจะสอนในปีแรก COMSC ในปีหน้า ในตัวอย่างที่สองฉันยอมรับอีกครั้งว่าเป็นการออกแบบ หากคุณแสดงให้ฉันเห็นทั้งความคิดเหล่านี้ฉันจะไม่สามารถใช้พวกเขาในโครงการซอฟต์แวร์แบบสุ่มของฉัน คุณต้องไปที่ 'ระดับสูงกว่า', Object Oriented (OO) ใน Java แทนที่จะต้องการให้คลาสลูกค้าเป็นคลาสย่อยของ Person Class แม้แต่การพูดคุยเกี่ยวกับข้อยกเว้นโดยทั่วไปก็ยังถือว่าอยู่ในระดับต่ำเกินไป (ใกล้เคียงกับการใช้งาน)

ในการพยายามระบุรายละเอียดที่คุณระบุฉันคิดว่าสิ่งที่คุณควรคำนึงถึงคือการออกแบบ CMS บนเว็บ Wordpress มีcodex สถาปัตยกรรมเว็บไซต์ที่พวกเขาพูดคุยกันมากเกี่ยวกับรายละเอียดการใช้งานการออกแบบ แต่ชัดเจนจากการโพสต์ที่ว่าศูนย์สถาปัตยกรรมหลักของพวกเขาทำให้ Wordpress สามารถขยายได้ด้วยธีม การสร้างอินเทอร์เฟซที่ชัดเจนสำหรับชุดรูปแบบที่สามารถเขียนได้โดยบางคนที่อยู่ด้านนอกของ บริษัท เป็นการตัดสินใจทางสถาปัตยกรรมที่ชัดเจน สิ่งเหล่านี้เป็นสิ่งที่ดีที่จะเขียนลงไปในกระดาษเมื่อสร้างโซลูชัน 'ระยะยาว' ของคุณ (ไม่ใช่ชั่วคราว) เพื่อให้การออกแบบและการตัดสินใจใช้งานทั้งหมดเกิดขึ้นระหว่างการพัฒนา (โดยนักพัฒนาทั้งหมดไม่ใช่แค่สถาปนิก) สอดคล้องกับแนวคิดนี้

ตัวอย่างอื่น ๆ ของสถาปัตยกรรมสำหรับสถานการณ์ของคุณ:

1. วางสิ่งทั้งหมดบนเครื่องเสมือนโฮสต์บนผู้ให้บริการคลาวด์หรือในบ้านและมีอินสแตนซ์ของเครื่องจักรไร้รัฐเพื่อให้สามารถแทนที่เครื่องที่ล้มเหลวด้วยอินสแตนซ์ใหม่ของเครื่องเสมือนโดยไม่ต้องคัดลอกข้ามรัฐหรือสูญเสียข้อมูลใด ๆ
2. การสร้างความล้มเหลวในการทดสอบการผลิตสดจากจุดเริ่มต้นที่มี Simians ความวุ่นวาย

อาจลองวาดทั้งระบบบนไวท์บอร์ด ลองในระดับรายละเอียดที่แตกต่างกันบอร์ดแรกอาจเป็น GUI-> โปรแกรมเลือกจ่ายงาน -> แบ็กเอนด์ -> DB หรือบางอย่างจากนั้นเจาะลึกลงไปจนกว่าคุณจะเริ่มใช้คำสรรพนาม

ความแตกต่างระหว่างความคิดสองข้อนี้สำคัญมากที่ฉันทำงาน

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

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

ตัวอย่างจากสิ่งที่ฉันทำ:

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

ไม่มีรหัส สามารถเขียนได้ทุกภาษา การใช้งานไม่ได้ถูกกำหนดโดยคำอธิบายนี้

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

อีกครั้งไม่มีอะไรในที่นี้กำหนดการใช้งานแม้ว่าการใช้งานบางอย่างจะมีประโยชน์มากกว่าผู้อื่นอย่างชัดเจน

ความแตกต่างระหว่างการออกแบบ (สิ่งที่เราเรียกรูปแบบหรือการนำไปใช้) และสถาปัตยกรรม (สิ่งที่เราเรียกว่าการออกแบบ) คือหนึ่งในนั้นแก้ปัญหาการเข้ารหัส / การนำไปใช้และอีกอันหนึ่งแก้ปัญหาโลกแห่งความจริง

บางทีนี่อาจช่วยได้ ฉันเคยเห็นรุ่นพี่ของวิศวกรมาโดยตลอดว่าเป็นปัญหาที่พวกเขาสามารถแก้ไขได้ด้วยตนเอง

ประมาณเพื่อถ่ายทอดความคิด:

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

• ผู้พัฒนาระดับกลางคือผู้ที่สามารถใช้คำอธิบายบางส่วนของแอปพลิเคชันและทำให้มันสามารถทำงานได้ในบริบทของแอปพลิเคชันนั้น

• นักพัฒนาอาวุโสสามารถสร้างแอปพลิเคชันขนาดกลางตั้งแต่เริ่มต้นภายใต้ข้อ จำกัด ทางเทคนิคของร้านค้า

• นักพัฒนาที่อาวุโสกว่าสามารถทำสิ่งนั้นและเลือกเทคโนโลยีตามวิธีที่เทคโนโลยีที่จะใช้เพื่อให้ทำงานได้ดี

... แต่นั่นไม่ใช่กฎที่ยากและรวดเร็ว และบางคนออกมาจากประตูในฐานะ "อาวุโส" IMHO แม้ว่าพวกเขาจะต้องใช้เวลากับชื่ออื่น

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

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

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

(BTW ฉันมีโค้งการเจริญเติบโตที่คล้ายกันอธิบายให้ฉันสำหรับสถาปนิกตั้งแต่การสร้างครอบครัวของแอปพลิเคชันที่เกี่ยวข้องหรือชุดของคุณสมบัติที่ซับซ้อนมากไปสู่การกำหนดทิศทางทางเทคนิคสำหรับกลุ่มเพื่อการตัดสินใจทางเทคนิคเชิงกลยุทธ์สำหรับทั้งองค์กร .)

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

... นี่เป็นการเปรียบเทียบ สมมติว่าคุณถูกขอให้สร้าง Magic Black Box ในฐานะวิศวกรคุณคาดว่าจะหลงใหลในผลงานภายในของ Magic Black Box แต่ในฐานะสถาปนิกความสนใจของคุณแตกต่างกัน คุณอาจมองเข้าไปในกล่องด้วยความอยากรู้อยากเห็น แต่คุณคาดว่าจะหมกมุ่นกับทุกสิ่งรอบ ๆกล่องดำเวทมนตร์

คล้ายกับการเปรียบเทียบคุณอาจคิดถึงบทบาทของสถาปัตยกรรมในการมองทั้งระบบว่าเป็นกล่องวิเศษ ดังนั้นถ้าคุณใช้ Gigantic Glass Box และคุณให้ลูกค้าแอพไคลเอนต์ไฟร์วอลล์ระดับการบริการฐานข้อมูลและแม้แต่ devops guys ภายในจากนั้นในฐานะสถาปนิกคุณจะต้องหมกมุ่นกับวิธีการสร้างกล่องระบบขนาดใหญ่นั้น ทำงานได้ดี

ความแตกต่างที่แน่นอนระหว่าง "การออกแบบ" และ "สถาปัตยกรรม" นั้นเป็นเรื่องส่วนตัวและมีการทับซ้อนกันบ้าง อย่างไรก็ตามนี่คือความแตกต่างที่ฉันเข้าใจ:

สถาปัตยกรรมดูแนวคิดระดับสูง ใครคือนักแสดงในระบบ? อะไรคือวัตถุหลักและวัตถุใดรับผิดชอบต่ออะไร เมื่อฉันคิดสถาปัตยกรรมฉันคิดว่า Visio ไม่ใช่รหัส

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

การออกแบบนั้นเกี่ยวข้องกับการสร้างต้นแบบการร่างส่วนต่อประสานของโค้ดโครงร่างโค้ดและอื่น ๆ มันอยู่ระหว่างสถาปัตยกรรมนามธรรมและงานระดับ "โค้ดลิง" ในระดับต่ำ

ในเฟรมเวิร์กเหตุการณ์การออกแบบอาจบอกว่า "เหตุการณ์ใช้อินเทอร์เฟซนี้" และ "มีกลุ่มเธรดซึ่งตัวจัดการเหตุการณ์ใช้เพื่อส่งเหตุการณ์ไปยังผู้ปฏิบัติงาน" การออกแบบสำหรับ MVC อาจเป็น "ใช้ไฮเบอร์เนตสำหรับรุ่นสปริงสำหรับคอนโทรลเลอร์และ GWT สำหรับมุมมอง"

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

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

ถ้าฉันสามารถเพิ่มอะไรที่นี่ก็ว่า: ไม่คิดว่ารหัส เลย

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

สำหรับกรณีการใช้งานเฉพาะของคุณคำถามด้านสถาปัตยกรรมที่มากกว่านี้ในความเห็นของฉันจะเป็นไปตาม:

• ทำไมคุณถึงใช้ MVC มันคือทั้งหมดที่คุณรู้ มีรูปแบบการใช้ที่ดีกว่านี้หรือไม่? ทำไม?
• กรอบอะไรคุณจะใช้และทำไม ?
• วิธีที่คุณจะขนาด? ไม่ฉลาดเพราะมันยังไม่สำคัญ เงื่อนไขอะไรที่จะขยายในแนวนอน คุณจะใช้บริการใดใน AWS
• การรับรองความถูกต้องจะดำเนินการอย่างไร ไม่ใช่รหัสฉลาด: คุณกำลังจะสร้างโทเค็นแบบสุ่มไม่ซ้ำกันในแต่ละคำขอและตรวจสอบโทเค็นที่คาดหวังหรือไม่ อย่าคิดว่าคุณจะทำสิ่งนี้ในรหัส ลองคิดดูว่าทำไมคุณถึงทำเช่นนี้เพราะสามารถทำได้ในภาษาเว็บใด ๆ ก็ตาม

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

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

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

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

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

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

นอกจากนี้ "บล็อกย่อย" บางส่วนจะยังคงซับซ้อนมากภายใต้ประทุน ดังนั้นการทำซ้ำของวิธีการ "บล็อกย่อย" อาจมีความจำเป็น แต่คราวนี้กับหนึ่งในโมดูลที่ระบุใหม่

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

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

ฉันพบว่ามันช่วยอธิบายปัญหาที่คุณพยายามแก้ไขก่อน ข้อกำหนดคืออะไร? ข้อ จำกัด คืออะไร? คุณสามารถพูดคุยกับผู้มีส่วนได้เสียเพื่อค้นหาข้อกำหนดเหล่านี้ได้หรือไม่?

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

และเนื่องจากนี่เป็นประสบการณ์การเรียนรู้อย่ากลัวที่จะถามคำถามแม้ว่าพวกเขาจะโง่