โมเดลสี่องค์ประกอบ
ขาสามข้างที่รองรับที่นั่งที่มีเป้าหมายชัดเจน
วิธีการพัฒนาซอฟต์แวร์ทั่วไปหยุดที่สามอย่าง: ระบบทำงานอย่างไร ระบบแทนอะไร และใครคุยกับใคร MDD เพิ่มรากฐานที่สี่ที่อีกสามส่วนต้องตอบรับ หากไม่มีที่นั่ง ขาก็เป็นแค่ขา
ขาที่ 1: HOW
ตรรกะ
รูปแบบการนำไปใช้ สถาปัตยกรรมบริการ อัลกอริทึม
ขาที่ 2: WHAT
สคีมา
โครงสร้างข้อมูล ระบบชนิดข้อมูล กฎการตรวจสอบ
ขาที่ 3: WHO
โปรโตคอล
สัญญาอินเทอร์เฟซ รูปแบบการสื่อสาร ขอบเขตบริการ
ที่นั่ง: WHY
พันธกิจ
กรอบจริยธรรมเชิงวัตถุวิสัยที่กำหนดวัตถุประสงค์และข้อจำกัดของระบบ
หลักการหลัก
การสอดคล้องอย่างต่อเนื่อง
ทุกการตัดสินใจด้านสถาปัตยกรรมต้องแสดงให้เห็นว่าสอดคล้องกับพันธกิจที่ระบุไว้ ตรรกะถูกท้าทาย: สิ่งนี้รับใช้พันธกิจหรือไม่? สคีมาถูกตรวจสอบ: โครงสร้างข้อมูลเหล่านี้สนับสนุนวัตถุประสงค์ของพันธกิจหรือไม่? โปรโตคอลถูกประเมิน: อินเทอร์เฟซเหล่านี้เอื้อให้บรรลุพันธกิจหรือไม่?
ข้อกำหนดของกรอบพันธกิจ
พันธกิจต้องเป็นอย่างไรจึงจะรับน้ำหนักได้
1. รากฐานจริยธรรมเชิงวัตถุวิสัย
• หลักการที่วัดได้ ไม่ใช่ค่านิยมเชิงความหวัง
• อัลกอริทึมที่ชัดเจนสำหรับการแก้ไขข้อขัดแย้ง
• ครอบคลุมหลายบริบทวัฒนธรรม
• การใช้เหตุผลทางจริยธรรมที่ตรวจสอบได้
2. การกำหนดเป้าหมายหลัก
• ให้คำแนะนำการตัดสินใจในสภาวะไม่แน่นอน
• กรองข้อเสนอที่ขัดแย้งกันโดยอัตโนมัติ
• สร้างพฤติกรรมที่มีความสอดคล้องกันในทุกองค์ประกอบ
• มั่นคงแม้มีการเปลี่ยนแปลงในการนำไปใช้
3. การบูรณาการในการปฏิบัติงาน
• แต่ละบริการต้องพิสูจน์เหตุผลในการมีอยู่
• สคีมาสะท้อนรูปแบบข้อมูลของพันธกิจ
• โปรโตคอลเอื้อต่อพฤติกรรมที่สอดคล้องกับพันธกิจ
• การทดสอบตรวจสอบความสอดคล้องกับพันธกิจ ไม่ใช่แค่การทำงาน
รูปแบบการนำไปใช้
แต่ละขามีคำถามที่ต้องตอบ
สถาปัตยกรรมบริการ
การกำหนดพันธกิจ → ความรับผิดชอบของบริการ → สัญญาอินเทอร์เฟซ → การนำไปใช้
• ความสอดคล้องกับพันธกิจ: บริการนี้ส่งเสริมเป้าหมายหลักอย่างไร?
• เหตุผลของขอบเขต: เหตุใดความรับผิดชอบนี้จึงต้องการบริการแยกต่างหาก?
• ความจำเป็นของอินเทอร์เฟซ: โปรโตคอลนี้เปิดใช้งานปฏิสัมพันธ์ใดที่สำคัญต่อพันธกิจ?
การออกแบบสคีมา
ข้อกำหนดพันธกิจ → โมเดลข้อมูล → ระบบชนิดข้อมูล → กฎการตรวจสอบ
• ความเกี่ยวข้องกับพันธกิจ: สคีมานี้บันทึกข้อมูลใดที่สำคัญต่อพันธกิจ?
• ข้อจำกัดพฤติกรรม: ชนิดข้อมูลเหล่านี้บังคับใช้พฤติกรรมที่สอดคล้องกับพันธกิจอย่างไร?
• แนวทางการพัฒนา: สคีมานี้ปรับตัวได้อย่างไรโดยยังรักษาความสอดคล้องกับพันธกิจ?
ข้อกำหนดโปรโตคอล
ปฏิสัมพันธ์ของพันธกิจ → ข้อกำหนดการสื่อสาร → การกำหนดสัญญา → การนำไปใช้
• บริบทพันธกิจ: โปรโตคอลนี้เปิดใช้งานการสื่อสารใดที่สำคัญต่อพันธกิจ?
• การบังคับใช้ข้อจำกัด: อินเทอร์เฟซนี้ป้องกันพฤติกรรมที่ละเมิดพันธกิจอย่างไร?
• ความสามารถในการรวมกัน: สัญญาเหล่านี้รวมกันเป็นระบบที่สอดคล้องกับพันธกิจอย่างไร?
การผสานกับการพัฒนาที่ยั่งยืน
การสอดคล้องกับพันธกิจในระยะยาวต้องการความเร็วที่รักษาได้
มาตรการต่อต้าน Goodhart
• การตรวจสอบความสอดคล้องระหว่างการนำไปใช้กับพันธกิจอย่างสม่ำเสมอ
• วัดการบรรลุพันธกิจ ไม่ใช่ตัวแทนที่บิดเบือนได้
• ปฏิเสธสิ่งที่เพิ่มเข้ามาแต่ไม่ช่วยเสริมพันธกิจ
การทำงานตามจังหวะ
• การทำงานที่สอดคล้องกับจังหวะความสามารถในการผลิต
• จุดตัดสินใจในตัวสำหรับการปรับทิศทางใหม่
• ความเร็วที่ยั่งยืนในฐานะข้อกำหนดระดับแรก
การตรวจสอบอย่างต่อเนื่อง
• การตั้งคำถามเกี่ยวกับความจำเป็นของแต่ละองค์ประกอบอย่างสม่ำเสมอ
• การตรวจสอบอย่างต่อเนื่องว่าพฤติกรรมสอดคล้องกับพันธกิจ
• การตรวจจับโดยอัตโนมัติเมื่อมีการเปลี่ยนแปลงที่ละเมิดพันธกิจ
ประตูควบคุมคุณภาพ
ประตูที่จะไม่เปิดหากไม่มีเหตุผลรองรับจากพันธกิจ
การตรวจสอบโค้ด
• ต้องอธิบายความสอดคล้องกับพันธกิจ
• การตรวจสอบข้อจำกัด
• การบูรณาการต้องเสริมความสอดคล้องโดยรวม
การทดสอบ
• ความถูกต้องเชิงการทำงาน
• การตรวจสอบความสอดคล้องกับพันธกิจ
• การทดสอบการปฏิเสธข้อจำกัดทางจริยธรรม
• ความยืดหยุ่นของข้อจำกัดภายใต้ความกดดัน
เอกสาร
• บริบทพันธกิจสำหรับทุกองค์ประกอบ
• เหตุผลสำหรับการแลกเปลี่ยนทางจริยธรรม
• วิธีที่ข้อจำกัดกำหนดรูปแบบการนำไปใช้
รูปแบบความล้มเหลว
MDD พังอย่างไร และยังคงอยู่ได้อย่างไร
การเบี่ยงเบนพันธกิจ
อาการ: ฟีเจอร์สะสมโดยไม่รับใช้พันธกิจหลัก การแก้ไข: การทบทวนสถาปัตยกรรมอย่างสม่ำเสมอโดยใช้ความสอดคล้องกับพันธกิจเป็นเกณฑ์
การระเบิดของความซับซ้อน
อาการ: ระบบไม่สามารถบำรุงรักษาได้เพราะความซับซ้อนที่ไม่จำเป็น การแก้ไข: ปฏิเสธสิ่งที่เพิ่มเข้ามาหากไม่เสริมการบรรลุพันธกิจ
ความไม่สอดคล้องทางจริยธรรม
อาการ: องค์ประกอบต่างๆ ใช้การใช้เหตุผลทางจริยธรรมไม่สม่ำเสมอ การแก้ไข: กรอบจริยธรรมที่รวมศูนย์พร้อมรูปแบบการนำไปใช้ร่วมกัน
ความสับสนในวัตถุประสงค์
อาการ: สมาชิกทีมสูญเสียการเชื่อมโยงระหว่างการตัดสินใจทางเทคนิคกับพันธกิจ การแก้ไข: การฝึกอบรมอย่างต่อเนื่องเกี่ยวกับการตัดสินใจที่ขับเคลื่อนด้วยพันธกิจ
กรณีศึกษา
CIRIS ตัวอย่างที่ผ่านการทดลองแล้ว
CIRIS (Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude) คือระบบที่ MDD ถูกพัฒนาขึ้นมาพร้อมกัน พันธกิจคือ เป้าหมายหลัก M-1: ส่งเสริมความสอดคล้องเชิงปรับตัวที่ยั่งยืน เพื่อให้สิ่งมีชีวิตที่หลากหลายสามารถแสวงหาการเจริญงอกงาม
ผลลัพธ์ทางสถาปัตยกรรม
• 22 บริการ แต่ละอย่างมีเหตุผลรองรับจากข้อกำหนดของพันธกิจ
• ตรวจสอบแล้วมากกว่า 200 API endpoints
• การทดสอบมากกว่า 10,000 รายการ โดยมีโครงสร้างข้อมูลที่ไม่ระบุชนิดน้อยมากในการใช้งานจริง
• ปรัชญา Ubuntu ที่ฝังอยู่ในการออกแบบโปรโตคอล
• Wisdom-Based Deferral ที่ป้องกันการละเมิดพันธกิจ (ดูความปลอดภัย)
• การใช้งานจริงในการดูแลชุมชน Discord
ปัจจัยความสำเร็จหลัก
• เป้าหมายหลักที่ชัดเจน: M-1 ให้เกณฑ์การตัดสินใจที่ไม่กำกวม
• จริยธรรมเชิงปฏิบัติการ: หลักการ Accord ที่นำไปใช้เป็นข้อจำกัดในโค้ด (อ่าน Accord)
• การพัฒนาที่ยั่งยืน: Grace เป็นเพื่อนร่วมทางที่บังคับใช้จังหวะที่ดีต่อสุขภาพ
• การตรวจสอบอย่างต่อเนื่อง: ทุกการตัดสินใจทางสถาปัตยกรรมถูกท้าทาย
แนวทางการนำไปใช้
วิธีเริ่มต้น จากจุดที่คุณอยู่
สำหรับโปรเจกต์ใหม่
1. กำหนดพันธกิจที่ชัดเจนพร้อมหลักการจริยธรรมที่วัดได้ก่อนเขียนโค้ด
2. กำหนดเป้าหมายหลักที่ให้คำแนะนำในการตัดสินใจ
3. ออกแบบสถาปัตยกรรมให้ข้อจำกัดของพันธกิจอยู่ในระดับรากฐาน
4. สร้างการตรวจสอบความสอดคล้องระหว่างพันธกิจกับเทคนิคอย่างต่อเนื่องตั้งแต่วันแรก
สำหรับโปรเจกต์ที่มีอยู่แล้ว
1. ตรวจสอบสถาปัตยกรรมปัจจุบันเพื่อหาข้อสมมติพันธกิจโดยนัย
2. กำหนดพันธกิจที่ชัดเจนซึ่งอธิบายรูปแบบการออกแบบที่มีอยู่
3. ระบุการละเมิดพันธกิจในการนำไปใช้ปัจจุบัน
4. วางแผนการปรับให้สอดคล้องอย่างค่อยเป็นค่อยไป โดยจัดลำดับความสำคัญตามผลกระทบต่อพันธกิจ
ข้อกำหนดเบื้องต้นของทีม
• มุ่งมั่นต่อการใช้เหตุผลทางจริยธรรมเชิงวัตถุวิสัย
• ยินดีปฏิเสธโซลูชันที่ดูดีแต่ไม่รับใช้พันธกิจ
• เชื่อว่าข้อจำกัดของพันธกิจสร้างสถาปัตยกรรมที่ดี ไม่ใช่จำกัดมัน
• แนวปฏิบัติการพัฒนาที่ยั่งยืนซึ่งรักษาการมุ่งเน้นในระยะยาว
ทิศทางต่อไป
MDD ไม่เหมาะสมกับทุกโปรเจกต์
MDD ถูกออกแบบสำหรับระบบที่พฤติกรรมทางจริยธรรมเป็นสิ่งสำคัญต่อพันธกิจ และความน่าเชื่อถือในระยะยาวมีความสำคัญมากกว่าความเร็วในการพัฒนาฟีเจอร์ระยะสั้น สำหรับระบบเหล่านั้น MDD ให้เส้นทางจากเจตนาทางจริยธรรมสู่ความเป็นจริงในการปฏิบัติงาน โดยใช้วินัยทางวิศวกรรมเดียวกันกับพันธกิจและโค้ด
ค่าใช้จ่ายเริ่มต้นเป็นเรื่องจริงขณะที่ทีมเรียนรู้การตัดสินใจที่ขับเคลื่อนด้วยพันธกิจ ผลตอบแทนที่สะสมอยู่ในการพัฒนาที่ตามมา: กรอบนี้ทำให้การตัดสินใจทางสถาปัตยกรรมชัดเจนขึ้น แทนที่จะเพิ่มจำนวนมากขึ้น