การออกแบบสถาปัตยกรรมทำได้อย่างไรในสภาพแวดล้อมที่คล่องตัว


59

ฉันได้อ่านหลักการสำหรับสถาปนิกว่องไวที่พวกเขานิยามหลักการต่อไป:

หลักการ # 1 ทีมที่ใช้รหัสออกแบบระบบ
หลักการ # 2 สร้างสถาปัตยกรรมที่ง่ายที่สุดที่อาจเป็นไปได้
หลักการ # 3 เมื่อมีข้อสงสัยรหัสมันออกมา
หลักการ # 4 พวกเขาสร้างมันพวกเขาทดสอบ
หลักการ # 5 ยิ่งระบบยิ่งใหญ่
หลักการ # 6 สถาปัตยกรรมของระบบคือการทำงานร่วมกันของบทบาท
หลักการ # 7 ไม่มีการผูกขาดกับนวัตกรรม

บทความกล่าวว่าการออกแบบสถาปัตยกรรมส่วนใหญ่เสร็จสิ้นในระหว่างขั้นตอนการเข้ารหัสและการออกแบบระบบก่อนหน้านั้นเท่านั้น นั่นเป็นเรื่องปกติ

ดังนั้นการออกแบบระบบทำได้อย่างไร? ใช้ UML หรือเปล่า หรือเอกสารที่กำหนดอินเทอร์เฟซและบล็อกหลัก อาจจะเป็นอย่างอื่น?


11
คุณไม่ได้ "ทำการออกแบบ" ใน UML คุณออกแบบและจากนั้นคุณใช้ UML เพื่อเขียนลงหรือสื่อสาร
tdammers

4
@tdammers: เพื่อความแม่นยำคุณลองใช้ UML เพื่อจดบันทึกและสังเกตว่า UML นั้นไม่เพียงพอ
Doc Brown

คำตอบ:


77

Disclaimer:ฉันamสถาปนิกในสภาพแวดล้อมที่เปรียว แต่เป็นเฮลฟอนมอลท์เคลเดอร์กล่าวว่า "ไม่มีแผนต่อสู้ชีวิตอยู่ติดต่อกับศัตรู" กล่าวอีกนัยหนึ่งการปฏิบัติจริงหมายความว่าไม่สามารถทำตามตัวอักษรที่แน่นอนของแนวทางได้

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

ดังนั้นการออกแบบระบบทำได้อย่างไร? ใช้ UML หรือเปล่า หรือเอกสารที่กำหนดอินเทอร์เฟซและบล็อกหลัก อาจจะเป็นอย่างอื่น?

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

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

  1. ข้อกำหนดที่ขยายเพิ่มและข้อกำหนดขอบเขต สิ่งเหล่านี้รวมถึงกรณีการใช้งานหรือเรื่องราวของผู้ใช้ที่เป็นไปตามข้อกำหนดทางธุรกิจระดับสูง โดยส่วนตัวฉันชอบใช้RFC 2119สำหรับความต้องการที่ไม่สามารถใช้งานได้ การออกแบบขึ้นอยู่กับและย้อนกลับไปที่เหล่านี้ แม้ว่ามันอาจจะไม่เหมาะกับคำจำกัดความทั่วไปของการออกแบบสิ่งเหล่านี้มักจะสำคัญพอ ๆ
  2. ภาพรวมประกอบด้วยเครือข่ายระดับสูงหรือแผนภาพส่วนประกอบและหน้าข้อความ นี่คือสำหรับกลุ่มเป้าหมายที่กว้างมากตั้งแต่ผู้บริหารระดับสูงไปจนถึงนักพัฒนาซอฟต์แวร์และฝ่ายควบคุมคุณภาพ สิ่งนี้ไม่ค่อยใช้ UML หรือเอกสารที่กำหนดเนื่องจากผู้ชมจำนวนมาก
  3. รายละเอียดสำหรับแต่ละองค์ประกอบมักมุ่งเน้นไปที่ส่วนต่อประสานหรือ API ระหว่างที่กล่าวถึงข้างต้น อินเทอร์เฟซอาจถูกระบุว่าเป็นลายเซ็นของวิธีการในภาษาเป้าหมายที่มีเงื่อนไขเบื้องต้นและรายละเอียด postcondition ส่วนประกอบอาจมีไดอะแกรมเครือข่ายเช่นการแสดงเลย์เอาต์ของ VM ในคลาวด์หรือศูนย์ข้อมูลและการเตรียมการด้านเครือข่าย ฐานข้อมูลเชิงสัมพันธ์มักจะมีไดอะแกรมความสัมพันธ์เอนทิตี
  4. รายการความเสี่ยงด้านสถาปัตยกรรมและการบรรเทาความเสี่ยงหากทราบ เช่นเดียวกับข้อกำหนดเหล่านี้แสดงให้เห็นถึงการตัดสินใจออกแบบและการแลกเปลี่ยน

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

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


3
นี่คือคำตอบที่ยอดเยี่ยมเกี่ยวกับบทบาทของสถาปนิกในทีม Agile ที่ควรจะเป็นอย่างไรก็ตามมันไม่ได้ตอบคำถามเกี่ยวกับสิ่งที่การออกแบบระบบคืออะไรก่อนที่การพัฒนาจะเริ่มขึ้นและแนวทางปฏิบัติที่ดีที่สุด
maple_shaft

@maple_shaft ฉันได้ขยายคำตอบของฉันเพื่อมุ่งเน้นที่การออกแบบมากขึ้น
akton

3
สำหรับสิ่งที่คุ้มค่าในฐานะที่เป็นสถาปนิกอีกคนที่ทำงานในสภาพแวดล้อมที่คล่องตัวมานานหลายปีในการตั้งค่าข้ามชาติที่สำคัญนี่คือจุดสำคัญ
Rex M

12

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

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

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

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


0

เมื่อทำการพัฒนาโดยใช้การทดสอบคุณจะสร้างโค้ดทดสอบที่ทดสอบโมดูลของคุณแยก (= เป็นอิสระจากโมดูลอื่น ๆ เท่าที่จะทำได้)

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

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

ในความคิดของฉัน tdd ยังเป็นงานสถาปัตยกรรม


ใช่ TDD เป็นงานสถาปัตยกรรม แต่อยู่บนส่วนประกอบซอฟต์แวร์ คำถามของฉันคือวิธีการสร้างสถาปัตยกรรมของโครงการขนาดใหญ่โดยใช้หลักการที่คล่องตัว
BЈовић
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.