แม่แบบบันทึกการตัดสินใจโดย arc42

https://arc42.org/overview

1. บทนำและเป้าหมาย

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

1.1 ภาพรวมข้อกำหนด

เนื้อหา

คำอธิบายสั้น ๆ ของข้อกำหนดเชิงฟังก์ชัน ปัจจัยขับเคลื่อน ข้อความที่ตัดตอน (หรือ สรุป) จากข้อกำหนด ลิงก์ไปยังเอกสารข้อกำหนด (ที่หวังว่ามีอยู่) พร้อมข้อมูลว่าหาได้ที่ไหน

แรงจูงใจ

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

รูปแบบ

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

เก็บข้อความที่ตัดตอนนี้ให้สั้นที่สุดเท่าที่เป็นไปได้ ชั่งน้ำหนักความอ่านง่ายของเอกสารนี้กับ ความซ้ำซ้อนที่อาจเกิดกับเอกสารข้อกำหนด

1.2 เป้าหมายด้านคุณภาพ

เนื้อหา

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

แรงจูงใจ

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

รูปแบบ

ตารางเป้าหมายด้านคุณภาพหลักและสถานการณ์ที่เป็นรูปธรรม เรียงตามลำดับความสำคัญ

1.3 ผู้มีส่วนได้ส่วนเสีย

เนื้อหา

ภาพรวมที่ชัดเจนของผู้มีส่วนได้ส่วนเสียของระบบ กล่าวคือบุคคล บทบาท หรือองค์กรทั้งหมดที่

• ต้องรู้จักสถาปัตยกรรม

• ต้องได้รับการโน้มน้าวเกี่ยวกับสถาปัตยกรรม

• ต้องทำงานกับสถาปัตยกรรมหรือโค้ด

• ต้องการเอกสารสถาปัตยกรรมสำหรับงานของตน

• ต้องตัดสินใจเกี่ยวกับระบบหรือการพัฒนา

แรงจูงใจ

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

รูปแบบ

ตารางที่มีชื่อบทบาท ชื่อบุคคล และความคาดหวังต่อสถาปัตยกรรมและ เอกสารของสถาปัตยกรรม

2. ข้อจำกัด

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

เนื้อหา

ข้อกำหนดทั้งหมดที่จำกัดสถาปนิกซอฟต์แวร์ในเสรีภาพเกี่ยวกับ การตัดสินใจด้านการออกแบบ การนำไปใช้ หรือกระบวนการพัฒนา ข้อจำกัดเหล่านี้บางครั้งใช้ กับทั้งองค์กรและบริษัท เกินกว่าระบบเดี่ยว ๆ

แรงจูงใจ

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

รูปแบบ

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

3. บริบทและขอบเขต

แยกระบบของคุณออกจากคู่สื่อสาร (ภายนอก) (ระบบข้างเคียงและผู้ใช้) ระบุอินเทอร์เฟซ ภายนอก แสดงจากมุมมองด้านธุรกิจ/โดเมน (เสมอ) หรือมุมมองทางเทคนิค (ทางเลือก)

เนื้อหา

ขอบเขตระบบและบริบท ตามชื่อ แยกระบบของคุณ (กล่าวคือขอบเขต) ออกจาก คู่สื่อสารทั้งหมด (ระบบข้างเคียงและผู้ใช้ กล่าวคือบริบทของระบบ) ด้วยวิธีนี้ จึงระบุอินเทอร์เฟซภายนอก

หากจำเป็น ให้แยกบริบททางธุรกิจ (อินพุตและเอาต์พุตเฉพาะโดเมน) ออกจากบริบททางเทคนิค (ช่องทาง โปรโตคอล ฮาร์ดแวร์)

แรงจูงใจ

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

รูปแบบ

ความเป็นไปได้ต่าง ๆ:

• แผนภาพบริบทต่าง ๆ

• รายการคู่สื่อสารและอินเทอร์เฟซของพวกเขา

3.1 บริบททางธุรกิจ

เนื้อหา

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

แรงจูงใจ

ผู้มีส่วนได้ส่วนเสียทุกคนควรเข้าใจสภาพแวดล้อมของระบบและข้อมูลใดที่ แลกเปลี่ยนกัน

รูปแบบ

แผนภาพทุกชนิดที่แสดงระบบเป็นกล่องดำและระบุอินเทอร์เฟซของโดเมน ไปยังคู่สื่อสาร

หรือ (เพิ่มเติม) ตาราง ชื่อเรื่องของตารางคือชื่อระบบของคุณ สามคอลัมน์ประกอบด้วยชื่อคู่สื่อสาร อินพุต และเอาต์พุต

3.2 บริบททางเทคนิค

เนื้อหา

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

แรงจูงใจ

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

รูปแบบ

เช่น แผนภาพการติดตั้งใช้งาน UML ที่อธิบายช่องทางไปยังระบบข้างเคียง พร้อมตารางการจับคู่ที่แสดงความสัมพันธ์ระหว่างช่องทางและอินพุต/เอาต์พุต

4. กลยุทธ์การแก้ปัญหา

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

เนื้อหา

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

• การตัดสินใจด้านเทคโนโลยี

• การตัดสินใจเกี่ยวกับการแยกส่วนระดับบนสุดของระบบ เช่น การใช้รูปแบบสถาปัตยกรรมหรือรูปแบบการออกแบบ

• การตัดสินใจเกี่ยวกับวิธีบรรลุเป้าหมายด้านคุณภาพหลัก

• การตัดสินใจด้านองค์กรที่เกี่ยวข้อง เช่น การเลือกกระบวนการพัฒนาหรือการมอบหมายงานบางอย่างให้บุคคลภายนอก

แรงจูงใจ

การตัดสินใจเหล่านี้เป็นรากฐานของสถาปัตยกรรมของคุณ เป็นพื้นฐานของการตัดสินใจโดยละเอียด หรือกฎการนำไปใช้อื่น ๆ อีกมากมาย

รูปแบบ

เก็บคำอธิบายการตัดสินใจหลักเหล่านี้ให้สั้น

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

คุณใช้รายการหรือตารางของแนวทางการแก้ปัญหาได้

5. มุมมองบล็อกโครงสร้าง

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

เนื้อหา

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

มุมมองนี้บังคับสำหรับเอกสารสถาปัตยกรรมทุกฉบับ เปรียบเทียบกับบ้าน นี่คือแปลนพื้น

แรงจูงใจ

รักษาภาพรวมของซอร์สโค้ดโดยทำให้โครงสร้างเข้าใจได้ผ่าน นามธรรม

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

รูปแบบ

มุมมองบล็อกโครงสร้างคือชุดลำดับชั้นของกล่องดำและกล่องขาว (ดูรูปด้านล่าง) และคำอธิบายของกล่องเหล่านั้น

5.1 กล่องขาวของระบบทั้งหมด

ที่นี่คุณอธิบายการแยกส่วนของระบบโดยรวมโดยใช้แม่แบบกล่องขาวต่อไปนี้ ซึ่งประกอบด้วย

• แผนภาพภาพรวม

• แรงจูงใจสำหรับการแยกส่วน

• คำอธิบายกล่องดำของบล็อกโครงสร้างที่มีอยู่ สำหรับสิ่งนี้มีทางเลือกดังนี้:

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

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

  • (ทางเลือก:) อินเทอร์เฟซสำคัญที่ไม่ได้อธิบายในแม่แบบกล่องดำของบล็อกโครงสร้าง แต่สำคัญมากต่อการเข้าใจกล่องขาว

เนื่องจากมีวิธีระบุอินเทอร์เฟซมากมาย เราจึงไม่ให้แม่แบบเฉพาะสำหรับสิ่งเหล่านั้น

ในกรณีที่ดีที่สุด ตัวอย่างหรือลายเซ็นอย่างง่ายก็เพียงพอ

5.2 ระดับ 2

ที่นี่คุณระบุโครงสร้างภายในของบล็อกโครงสร้างบางตัวจากระดับ 1 เป็นกล่องขาวได้

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

5.2.1 กล่องขาวของบล็อกโครงสร้าง 1

...อธิบายโครงสร้างภายในของบล็อกโครงสร้าง 1

ใช้แม่แบบกล่องขาว (ดูข้างต้น)

6. มุมมองขณะทำงาน

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

เนื้อหา

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

• กรณีใช้งานหรือฟังก์ชันสำคัญ: บล็อกโครงสร้างดำเนินการอย่างไร

• การโต้ตอบที่อินเทอร์เฟซภายนอกที่สำคัญ: บล็อกโครงสร้างทำงานร่วมกับผู้ใช้และระบบข้างเคียงอย่างไร

• การดำเนินงานและการดูแลระบบ: การบูต การเริ่ม การหยุด

• สถานการณ์ข้อผิดพลาดและข้อยกเว้น

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

แรงจูงใจ

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

รูปแบบ

มีสัญกรณ์มากมายสำหรับอธิบายสถานการณ์ เช่น

• รายการขั้นตอนที่มีหมายเลข (ในภาษาธรรมชาติ)

• แผนภาพกิจกรรมหรือผังงาน

• แผนภาพลำดับ

• BPMN หรือ EPC (ห่วงโซ่กระบวนการเหตุการณ์)

• เครื่องสถานะ

• ฯลฯ

6.n สถานการณ์ขณะทำงาน n (1, 2, 3 ฯลฯ)

ใส่แผนภาพขณะทำงานหรือคำอธิบายเป็นข้อความของสถานการณ์

ใส่คำอธิบายแง่มุมที่น่าสังเกตของการโต้ตอบระหว่างอินสแตนซ์ของบล็อกโครงสร้างที่ปรากฏในแผนภาพนี้

7. มุมมองการติดตั้งใช้งาน

โครงสร้างพื้นฐานทางเทคนิคพร้อมสภาพแวดล้อม คอมพิวเตอร์ ตัวประมวลผล และโทโพโลยี การจับคู่บล็อกโครงสร้าง (ซอฟต์แวร์) กับองค์ประกอบโครงสร้างพื้นฐาน

เนื้อหา

มุมมองการติดตั้งใช้งานอธิบาย:

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

• การจับคู่บล็อกโครงสร้าง (ซอฟต์แวร์) กับองค์ประกอบโครงสร้างพื้นฐานเหล่านั้น

ระบบมักทำงานในสภาพแวดล้อมต่างกัน เช่น สภาพแวดล้อมการพัฒนา สภาพแวดล้อมการทดสอบ สภาพแวดล้อมการผลิต ในกรณีเช่นนั้น คุณควร บันทึกสภาพแวดล้อมที่เกี่ยวข้องทั้งหมด

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

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

แรงจูงใจ

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

รูปแบบ

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

• UML มีแผนภาพการติดตั้งใช้งานเพื่อแสดงมุมมองนั้น ใช้มัน อาจใช้แผนภาพซ้อน เมื่อโครงสร้างพื้นฐานของคุณซับซ้อนกว่า

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

7.1 โครงสร้างพื้นฐานระดับ 1

อธิบาย (โดยทั่วไปเป็นการผสมของแผนภาพ ตาราง และข้อความ):

• การกระจายของระบบไปยังหลายสถานที่ สภาพแวดล้อม คอมพิวเตอร์ ตัวประมวลผล ฯลฯ รวมถึงการเชื่อมต่อทางกายภาพระหว่างกัน

• เหตุผลหรือแรงจูงใจที่สำคัญสำหรับโครงสร้างการติดตั้งใช้งานนี้

• คุณลักษณะด้านคุณภาพและ/หรือประสิทธิภาพของโครงสร้างพื้นฐาน

• การจับคู่ผลงานซอฟต์แวร์ (บล็อกโครงสร้าง) กับองค์ประกอบของโครงสร้างพื้นฐาน

สำหรับหลายสภาพแวดล้อมหรือการติดตั้งใช้งานทางเลือก ให้คัดลอกส่วนนั้นของ arc42 สำหรับสภาพแวดล้อมที่เกี่ยวข้องทั้งหมด **

7.2 โครงสร้างพื้นฐานระดับ 2

อาจรวมโครงสร้างภายในของบางองค์ประกอบโครงสร้างพื้นฐานจากระดับ 1

คัดลอกโครงสร้างจากระดับ 1 สำหรับแต่ละองค์ประกอบที่เลือก

8. แนวคิดข้ามส่วน

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

เนื้อหา

ส่วนนี้อธิบายแนวคิดข้ามส่วน (แนวปฏิบัติ รูปแบบ กฎเกณฑ์ หรือแนวคิดการแก้ปัญหา) แนวคิดเหล่านี้มักเกี่ยวข้องกับหลายบล็อกโครงสร้าง อาจครอบคลุมหัวข้อต่าง ๆ มากมาย

แรงจูงใจ

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

นี่คือที่ที่เราสร้างไว้ในแม่แบบสำหรับข้อกำหนดที่สอดคล้องกันของแนวคิดเหล่านี้

แนวคิดเหล่านี้หลายอย่างเกี่ยวข้องหรือส่งผลต่อหลายบล็อกโครงสร้าง

รูปแบบ

รูปแบบอาจแตกต่างกัน:

• เอกสารแนวคิดที่มีโครงสร้างใดก็ได้

• การนำไปใช้ตัวอย่าง โดยเฉพาะสำหรับแนวคิดทางเทคนิค

• ข้อความที่ตัดตอนจากแบบจำลองข้ามส่วนหรือสถานการณ์โดยใช้สัญกรณ์ของมุมมองสถาปัตยกรรม

โครงสร้างของส่วนนี้

เลือกเฉพาะหัวข้อที่จำเป็นที่สุดสำหรับระบบของคุณและให้แต่ละหัวข้อมีหัวเรื่องระดับ 2 ในส่วนนี้ (เช่น 8.1, 8.2 ฯลฯ)

• อย่าพยายามครอบคลุมทุกหัวข้อจากแผนภาพข้างต้น

ภูมิหลัง

บางหัวข้อภายในระบบมักเกี่ยวข้องกับหลายบล็อกโครงสร้าง องค์ประกอบ ฮาร์ดแวร์ หรือกระบวนการพัฒนา อาจง่ายกว่าที่จะสื่อสารหรือบันทึกหัวข้อข้ามส่วนเหล่านั้นไว้ที่เดียว กลางแทนที่จะทำซ้ำในคำอธิบายของบล็อกโครงสร้าง องค์ประกอบฮาร์ดแวร์ หรือ กระบวนการพัฒนาที่เกี่ยวข้อง

แนวคิดบางอย่างอาจเกี่ยวข้องกับทุกองค์ประกอบของระบบ แนวคิดอื่นอาจเกี่ยวข้องกับเพียงบางองค์ประกอบ

9. การตัดสินใจด้านสถาปัตยกรรม

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

เนื้อหา

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

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

แรงจูงใจ

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

รูปแบบ

• ADR (บันทึกการตัดสินใจด้านสถาปัตยกรรม) สำหรับทุกการตัดสินใจที่สำคัญ

• รายการหรือตาราง เรียงตามความสำคัญและผลที่ตามมา หรือ

• ละเอียดกว่าในส่วนแยกสำหรับแต่ละการตัดสินใจ

ภูมิหลัง (เกี่ยวกับ ADR)

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

• การตัดสินใจ เพราะเห็นได้ เช่น ในซอร์สโค้ด แต่

• ขาดแรงจูงใจเบื้องหลังการตัดสินใจนั้น (ดู Nygard 2011)

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

ข้อเสนอของเราสำหรับการตัดสินใจ

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

10. ข้อกำหนดด้านคุณภาพ

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

เนื้อหา

ส่วนนี้ประกอบด้วยข้อกำหนดด้านคุณภาพที่เกี่ยวข้องทั้งหมด

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

แรงจูงใจ

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

ข้อมูลเพิ่มเติม

ดูแบบจำลองคุณภาพ Q42 ที่ครอบคลุมได้ที่ https://quality.arc42.org

10.1 ภาพรวมข้อกำหนดด้านคุณภาพ

เนื้อหา

ภาพรวมหรือสรุปของข้อกำหนดด้านคุณภาพ

แรงจูงใจ

บ่อยครั้งคุณเผชิญกับข้อกำหนดด้านคุณภาพโดยละเอียดหลายสิบ (หรือแม้แต่หลายร้อย) ข้อ ในส่วนภาพรวมนี้ คุณควรพยายามสรุป เช่น โดยอธิบายหมวดหมู่หรือหัวข้อ (ตามที่ ISO 25010:2023 หรือ Q42 เสนอ)

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

รูปแบบ

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

ในวรรณกรรมยังมีการอธิบายแนวคิดของต้นไม้คุณลักษณะด้านคุณภาพ ซึ่งมีคำทั่วไปว่า "คุณภาพ" เป็นราก และ ขยายความคำว่า "คุณภาพ" ในโครงสร้างต้นไม้ [Bass+21] นำคำว่า "Quality Attribute Utility Tree" มาใช้เพื่อจุดประสงค์นี้

10.2 สถานการณ์ด้านคุณภาพ

เนื้อหา

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

สถานการณ์สองประเภทมีประโยชน์เป็นพิเศษ:

• สถานการณ์การใช้งาน (เรียกอีกอย่างว่าสถานการณ์แอปพลิเคชันหรือสถานการณ์กรณีใช้งาน) อธิบายปฏิกิริยาขณะทำงานของระบบต่อ สิ่งกระตุ้นหนึ่ง ซึ่งรวมถึงสถานการณ์ที่อธิบายประสิทธิภาพหรือ สมรรถนะของระบบ ตัวอย่าง: ระบบตอบสนองต่อคำขอของผู้ใช้ภายในหนึ่งวินาที

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

รูปแบบ

ข้อมูลทั่วไปในสถานการณ์โดยละเอียดประกอบด้วย:

รูปแบบสั้น (เป็นที่นิยมในแบบจำลอง Q42):

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

• แหล่งที่มา/สิ่งกระตุ้น: ใครหรืออะไรเริ่มหรือกระตุ้นการกระทำ ปฏิกิริยา หรือพฤติกรรม

• เมตริก/เกณฑ์การยอมรับ: การตอบสนอง รวมถึงมาตราส่วนหรือเมตริก

รูปแบบยาวของสถานการณ์ (SEI และ [Bass+21] นิยม) ละเอียดกว่าและมีข้อมูลต่อไปนี้:

• รหัสสถานการณ์: ตัวระบุที่ไม่ซ้ำสำหรับสถานการณ์

• ชื่อสถานการณ์: ชื่อสั้นเชิงพรรณนาสำหรับสถานการณ์

• แหล่งที่มา: เอนทิตี (ผู้ใช้ ระบบ หรือเหตุการณ์) ที่เริ่มสถานการณ์

• สิ่งกระตุ้น: เหตุการณ์หรือเงื่อนไขที่กระตุ้นซึ่งระบบต้องตอบสนอง

• สภาพแวดล้อม: บริบทการทำงานหรือเงื่อนไขที่ระบบประสบกับสิ่งกระตุ้น

• ผลงาน: บล็อกโครงสร้างหรือองค์ประกอบอื่นของระบบที่ได้รับผลกระทบจากสิ่งกระตุ้น

• การตอบสนอง: ผลลัพธ์หรือพฤติกรรมที่ระบบแสดงเป็นการตอบสนองต่อสิ่งกระตุ้น

• มาตรวัดการตอบสนอง: เกณฑ์หรือเมตริกที่ใช้ประเมินการตอบสนองของระบบ

ดูเพิ่มเติม

ตั้งแต่เดือนมกราคม 2023 arc42 มีแบบจำลองคุณภาพเชิงปฏิบัติที่เสนอให้ติดแท็กข้อกำหนดด้านคุณภาพ ด้วยแฮชแท็กหรือป้ายกำกับ เช่น #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable

11. ความเสี่ยงและหนี้ทางเทคนิค

ความเสี่ยงทางเทคนิคหรือหนี้ทางเทคนิคที่ทราบ มีปัญหาที่อาจเกิดขึ้นอะไรในหรือรอบระบบ ทีมพัฒนากำลังประสบปัญหาอะไร

เนื้อหา

รายการที่จัดลำดับความสำคัญของความเสี่ยงทางเทคนิคหรือหนี้ทางเทคนิคที่ระบุไว้

แรงจูงใจ

"การจัดการความเสี่ยงคือการจัดการโครงการสำหรับผู้ใหญ่" (Tim Lister, Atlantic Systems Guild)

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

รูปแบบ

รายการความเสี่ยงและ/หรือหนี้ทางเทคนิค อาจมีมาตรการที่เสนอเพื่อ ลด บรรเทา หรือหลีกเลี่ยงความเสี่ยงหรือลดหนี้ทางเทคนิค