Software Architectural Design Principles

ขอแนะนำหลักพื้นฐานการออกแบบสถาปัตยกรรมซอฟต์แวร์ที่ควรทราบและใช้ให้ชำนาญกันครับ หลักการพื้นฐานเหล่านี้สำคัญและจำเป็นมากๆๆ ต่อการออกแบบซอฟต์แวร์ หรือระบบไอที architect ควรเลือกใช้ให้เหมาะสม ออกแบบกลไกภายใน ตลอดจนถึงการอิมพลีเม้นต์ และการควบคุมการอิมพลีเม้นต์ให้สัมพันธ์กับงานออกแบบ เพื่อสนับสนุน quality attribute ที่ต้องการ เพื่อให้ stakeholder ทุกๆ คนได้ happyๆๆ กันครับ ผมอธิบายแค่แนวคิดคร่าวๆ นะครับ อยากให้ไปศึกษา ฝึกฝน ทบทวน ในเชิงลึกกันต่อไป สงสัยไม่เข้าใจติดตรงไหนสอบถามมาได้ครับ

อ้อ อย่าลืม… อย่าเป็นคนมักง่าย ใจเร็วด่วนได้ แก้ปัญหาเฉพาะหน้า ด้วยการเริ่มต้นที่เทคโนโลยีนะครับ… การฝึกเป็น architect ที่ดี ต้องฝึกแก้ปัญหาด้วย design principle หรือใช้ร่วมกับ pattern และ tactic ก่อน ซึ่งการคิดถึงเทคโนโลยีนั้นมาทีหลังนะครับ พวกเฟรมเวิร์ก ไลบรารี่ อะไรพวกนี้ด้วยมาทีหลังครับ ฝึกแก้ปัญหาทางสถาปัตยกรรมด้วยแนวคิดพื้นฐานให้คล่องเสียก่อน ถ้าชำนาญเมื่อไร เจอปัญหาอะไรก็ไม่ต้องกลัวครับ แถมหลักการพื้นฐานเหล่านี้อยู่ไปอีกนานหลายชั่วอายุคน ใช้ได้ไปอีกนาน ไม่เหมือนเทคโนโลยีที่เปลี่ยนไวปานความเร็วแสงกันอยู่แล้ว…

มาลุยกันเลย…

Monitoring

  • Monitoring คือ การติดตามอิลิเม้นต์ใดอิลิเม้นต์หนึ่ง หรือเหตุการณ์ใดเหตุการณ์หนึ่ง เพื่อเฝ้าสังเกตการณ์เปลี่ยนแปลง state เมื่อ state ของสิ่งนั้นเปลี่ยนแปลงไปจนสบเงื่อนไขตามที่กำหนดไว้จะทำงานตามคำสั่งที่ผูกไว้
  • อิลิเม้นต์ที่ทำหน้าที่ติดตามในทางไอทีบางทีใช้คำว่า monitor หรือ listener อาทิ transaction monitor, port listener,event listener
  • ลักษณะการทำงานของ monitor และ listenerคือเป็นthreadที่ทำงานตลอดเวลาดังนั้นการออกแบบโดยใช้ Monitoring จึงควรมีพื้นฐานด้าน multi-thread, synchronization, schedulingเป็นอย่างดี
  • Monitoring ช่วยให้เกิดการทำงานแบบอัตโนมัติเพราะตัวmonitorหรือlistenerจะเฝ้าติดตามและปฏิบัติงานตามข้อกำหนดที่ระบุไว้ล่วงหน้าด้วยตัวมันเองโดยไม่ต้องมีactionจากไคลเอ็นต์เข้าเรียกตัวมันโดยตรง
  • Monitoring มีการใช้ I/O มากในการแจ้งสถานะไปยังอิลิเม้นต์ที่ต้องรับทราบข้อมูล และอาจใช้ซีพียูมากกรณีมีตัว monitor หรือ listener จำนวนมากทำงานอยู่ เพราะต้องมีการจัดการด้าน synchronization, multi-threading ดังนั้นจึงนิยมควบคุมด้วยการกำหนด priority และจัดสรรให้เหมาะสมกับ performance ที่ต้องการ

 

Prototype & Template

  • Prototype คือ ต้นแบบ การออกแบบที่ดีไม่ควรพยายามออกแบบคราวเดียวให้เสร็จสมบูรณ์ เพราะกรณีที่ปัญหาหรืองานมีความซับซ้อนและมีรายละเอียดมาก ควรค่อยๆ ออกแบบ หากไม่แน่ใจในโซลูชั่นที่ใช้ จึงควรสร้าง Prototype ขึ้นมาทดสอบสมมติฐาน
  • Prototype มีได้หลายรูปแบบ ตั้งแต่ภาพสเก็ตช์, ภาพโมเดลที่สร้างด้วยไดอะแกรมชนิดต่างๆ, ระบบต้นแบบ
  • นอกจากนี้ Prototype ยังให้ความหมายในมุมมองด้านการต่อยอด โดยการ copy หรือ clone ตัว Prototype แล้วนำตัวที่ copy หรือ clone ไปปรับปรุงต่อยอด เพื่อไม่ให้กระทบกับตัว Prototype
  • Template คือ แบบแผนที่ใช้เป็นแนวทางในการดำเนินงาน เพื่อให้มีความถูกต้อง, มีมาตรฐาน อาทิ Template เอกสารต่างๆ, Template อัลกอริธึมการทำงานของเมธอด (เช่น การเชื่อมต่อกับ database), Template หน้าจอ เป็นต้น
  • Template ยังช่วยในด้าน reuse, การออกแบบระบบที่มีรายละเอียดมาก, มีอิลิเม้นต์ประเภทเดียวกันจำนวนมาก รวมถึงการมีทีมงานหลายคน จึงควรสร้าง Template เอาไว้ใช้ เพื่อควบคุมไม่ให้เกิดความหลากหลายจนจัดการยาก และไม่ให้ดำเนินงานไปผิดจากที่ต้องการ

 

Activation & Passivation

  • Activation คือ การนำอิลิเม้นต์ที่อยู่ในสถานะ block หรือ passive ที่มักถูกเก็บอยู่ในดิสก์กลับขึ้นไปอยู่ในสถานะ active เพื่อทำงาน ที่มักอยู่ในหน่วยความจำ การทำงานนี้เรียกได้หลายอย่าง อาทิ Swap-In, Object De-Serialization
  • Passivation คือ การนำอิลิเม้นต์ที่อยู่ในสถานะว่าง (idle หรือ inactive) โดยมีกลไกจัดการซึ่งมักใช้อัลกอริธึม LRU (Least Recently Use) และ LFU (Lease Frequently Use) โดยอิลิเม้นต์นั้นๆ มักอยู่ในหน่วยความจำ แต่ไม่ค่อยได้ถูกใช้งาน จึงนำออกไปเก็บไว้ในสถานะ block หรือ passive ซึ่งมักเก็บลงดิสก์ การทำงานนี้เรียกได้หลายอย่าง อาทิ Swap-Out, Object Serialization
  • การจัดการด้าน Activation และ Passivation ช่วยในการบริหารทรัพยากร ช่วยด้าน performance, stability (เสถียรภาพ), scalability (การรองรับการขยายตัว) และคุณภาพอีกหลายประการ
  • Activation และ Passivation ใช้ I/O เป็นหลัก จึงทำบ่อยมากเกินไปไม่ดี จึงต้องกำหนดเกณฑ์ของ LRU และ LFU ให้ดี

 

Balance Concerns & Separation of Concerns

  • Concern คือ ความกังวลของ stakeholder หรือประเด็นสำคัญของระบบ
  • Balance Concerns คือ
    • การออกแบบโดยคำนึงถึง stakeholder หลัก ว่าพวกเขากังวลหรือให้ความสนใจประเด็นใดมากเป็นพิเศษ โดยไม่ใช้อัตตาความชอบ/ความสนใจ/ความชำนาญของตนเองชี้นำโซลูชั่นที่เลือกใช้
    • การออกแบบโดยให้ความสำคัญกับประเด็นสำคัญหรือส่วนสำคัญหลักของระบบ โดยไม่มุ่งเน้นไปที่ส่วนใดส่วนหนึ่งมากหรือน้อยเกินไป
    • แบ่ง Concern เป็น 2 ประเภทง่ายๆ ได้เป็น Business Concern และ Technical Concern โดยให้น้ำหนักและพิจารณา Business Concern ก่อน
  • Separation of Concerns คือ การแยก Concern เพื่อจำแนกให้เป็นหมวดหมู่ชัดเจน ลดความซ้ำซ้อน

 

Communication Path & Access Channel

  • Communication Path คือ การกำหนดเส้นทางการสื่อสารระหว่างอิลิเม้นต์ต่างๆ (เช่น โมดูล, อ็อบเจ็คต์) ภายในสภาพแวดล้อมของระบบ คล้ายการกำหนดถนนและเส้นทางคมนาคม
  • Communication Path มีวัตถุประสงค์เพื่อกำหนดเส้นทางการสื่อสารหรือ process/flow ที่เป็นมาตรฐาน เป็นระเบียบ เพื่อให้จัดการและปรับปรุงได้ง่าย มีผลต่อคุณภาพหลายด้าน เช่น performance, modifiability เป็นต้น
  • Access Channel คือ การกำหนดช่องทางการเข้าถึงอิลิเม้นต์ (เช่น เซอร์วิส, เว็บเพจ, โมดูล, อ็อบเจ็คต์) โดยอาจกำหนดทั้งด้านเครือข่าย, ฮาร์ดแวร์ และซอฟต์แวร์ เช่น กำหนดไฟร์วอลล์, โปรโตคอล, เครื่องที่เฉพาะเจาะจง, สิทธิ เป็นต้น
  • Access Channel มีวัตถุประสงค์เพื่อกำหนดช่องทางให้เป็นระเบียบ มีผลต่อคุณภาพหลายด้าน เช่น security, performance, modifiability เป็นต้น

 

Filter

  • Filter คือ การทำงานในส่วน pre-condition หรือ entry event และในส่วน post-condition หรือ exit event
  • Filter มักใช้ในบริบทเกี่ยวกับเน็ตเวิร์ก อาทิ การกรอง request ที่มาจากไคลเอ็นต์ก่อนจะเข้าสู่ระบบ, การกรอง response ที่จะออกจากระบบไปสู่ไคลเอ็นต์
  • Filter ยังช่วยลดโอเวอร์เฮดของระบบลงได้ด้วยการประมวลผล request บางเรื่องก่อนที่ request จะเข้าสู่ภายในระบบ การประมวลผลดังกล่าว อาทิ validate user, validate form, validate session, encode character set ส่วนการประมวลผล response เป็นการช่วยลดโอเวอร์เฮดให้กับไคลเอ็นต์และ เน็ตเวิร์ก การประมวลผล filter ส่วน response อาทิ convert data format, ลบ sensitive data ออกจากเฮดเดร์ของโปรโตคอล เป็นต้น

 

Domain

  • Domain คือ ประเด็นสำคัญภายในบริบท (context) ที่ประกอบด้วยองค์ประกอบต่างๆ มักแบ่งเป็น domain class (เรียกได้หลายอย่าง เช่น domain data, domain entity), domain knowledge (องค์ความรู้หลัก) และ domain logic ซึ่งประกอบด้วย business logic กับ data logic
  • Domain มักใช้ในแง่การจัดกลุ่มประเด็นสำคัญ นอกจากนี้ยังมีแนวทางการออกแบบที่มีประโยชน์มากๆ เรียกว่า ‘Domain-Driven Design’ ที่ใช้การขับเคลื่อนกระบวนการออกแบบด้วย Domain

 

Logic Allocation

  • Logic Allocation คือ การจัดวางลอจิกให้กับอิลิเม้นต์ให้เป็นที่เป็นทางเป็นระเบียบ โดยคำนึงถึงหลัก Modularity เพื่อไม่ให้เกิดความซ้ำซ้อนที่ไม่จำเป็น นิยมแบ่งกลุ่มลอจิกออกเป็นชั้นๆ เรียกว่า ‘Architectural Layer’
  • Architectural Layer คือ การจัดวางกลุ่มอิลิเม้นต์ที่มีลอจิกประเภทเดียวกันไว้ในเลเยอร์เดียวกัน ซึ่งเลเยอร์สะท้อนถึงโครงสร้างสถาปัตยกรรมเพราะถือเป็นการจัดวางโครงสร้างของลอจิกนั่นเอง ทั้งนี้ยังต้องคำนึงถึง Reusability ของแต่ละเลเยอร์ด้วย ระบบโดยทั่วไปควรมีตั้งแต่ 3 เลเยอร์ขึ้นไป ได้แก่
    • Presentation Layer คือ เลเยอร์ที่ประกอบด้วยอิลิเม้นต์ที่มีลอจิกเกี่ยวกับการแสดงผล
    • Business Service Layer คือ เลเยอร์ที่ประกอบด้วยอิลิเม้นต์ที่มีลอจิกเกี่ยวกับการประมวลผลการทำงานหลักของระบบ อาทิ ทรานแซกชั่น
    • Business Domain Layer คือ เลเยอร์ที่ประกอบด้วยอิลิเม้นต์ที่มีลอจิกเกี่ยวกับ domain บางทีก็เรียกเลเยอร์นี้ว่า Data Layer
  • architectural style แบบ Web Application มักแยกส่วน application logic ออกจาก Business Service Layer ออกเป็น Application Layer

 

Verification & Validation

  • Verification คือ การตรวจสอบตามกฎ อาทิ syntax, rule, format ผลลัพธ์มักเป็น ถูก, ผิด, ใช่, ไม่ใช่ เช่น กำหนดว่าหมายเลขโทรศัพท์มือถือต้องป้อนเป็นตัวเลขทั้งหมด 10 ตัว โดยไม่มีตัวอักษร: 0811234567 (ถูก), 081-1234567 (ผิด)
  • Validation คือ การตรวจสอบตามเกณฑ์ ผลลัพธ์มักเป็น ผ่าน, ไม่ผ่าน เช่น ผู้ใช้ต้องป้อนข้อมูลลงแบบฟอร์มให้ครบถ้วนและถูกต้องตามเงื่อนไขในแต่ละข้อ จึงจะ submit ผ่าน
  • จึงมักทำ Verification ก่อน Validation
  • การตรวจสอบควรวางหรือกระจายให้เหมาะสม อย่าให้เกิดความซ้ำซ้อนมากเกินไป
  • การตรวจสอบถือเป็น business logic ประเภทหนึ่ง
  • การตรวจสอบใดที่มีน้ำหนัก business logic มากๆ ไม่ควรวางไว้ที่หน้าจอ ควรวางไว้ที่เลเยอร์ Business Domain หรือที่คลาส domain อาทิ การตรวจสอบรายละเอียดข้อมูลประกอบการคำนวณดอกเบี้ย
  • การมีการตรวจสอบที่มากเกินไป หรือเป็นแบบ ‘ย้ำคิดย้ำทำ’ ก่อให้เกิดโอเวอร์เฮดส่งผลต่อ response time ในด้าน performance

 

Application Flow Control

  • Application Flow Control คือ การควบคุมพลวัตการทำงานของระบบตั้งแต่เมื่อมี request เข้ามา จนกระทั่งประมวลผลเสร็จแล้วส่ง response ออกไป
  • สถาปัตยกรรมระบบใดๆ ต้องกำหนดรูปแบบโฟลว์ของระบบให้ชัดเจนเป็นระเบียบ แบ่งส่วนการทำงานต่างๆ ให้ชัดเจน โดยใช้ Architectural Layer ร่วมจัดกลุ่มลอจิกและวางโครงสร้างได้
  • สถาปัตยกรรมระบบใดๆ ควรมี Application Flow ที่มีรูปแบบชัดเจน ไม่หลากหลายเกินไป ควรใช้ร่วมกับการวาง Communication Path โดยให้นึกถึงการวางผังเมือง ที่ต้องวางถนนหนทางต่างๆ อย่างเป็นระเบียบ ไม่ซับซ้อนยุ่งเหยิงอย่างจังหวัดกรุงเทพฯ เพราะการวาง Application Flow ที่ดีจะเกิดการติดขัดของโฟลว์น้อยมาก มีประโยชน์ต่อคุณภาพทั้งด้าน performance กับการจัดการ
  • โดยทั่วไปมักต้องมีอิลิเม้นต์ที่ทำหน้าที่ควบคุมโฟลว์โดยเฉพาะ อาทิ Controller ที่มีหน้าที่ประมวลผล request กับ response ด้วยการรับ-ส่ง request ไปยังอิลิเม้นต์ต่างๆ ที่เหมาะสม ก่อนพิจารณา response แล้วส่งออกไปยังไคลเอ็นต์

 

Distribution

  • Distribution คือ การกระจายสิ่งที่ไม่ควรอยู่ด้วยกันให้ออกไปอยู่แยกกัน (มักแยกเครื่องกัน)  เพื่อไม่ให้เกิดการกระจุกตัว อันมีผลต่อการเกิดคอขวด, โอเวอร์เฮด, deadlock และยังช่วยให้บริหารจัดการง่าย
  • Distribution ยังช่วยลด Coupling และเพิ่มระดับ Cohesion และ Modularity ให้กับแต่ละส่วนที่กระจายกันออกไป
  • Distribution Type มีหลายประเภท อาทิ
    • Distributed Object คือ การกระจายอ็อบเจ็คต์
    • Distributed Service คือ การกระจายเซอร์วิส
    • Distributed Resource คือ การกระจายทรัพยากร
    • Distributed Data คือ การกระจายข้อมูล
    • Distributed Processing คือ การกระจายการประมวลผล
    • Distributed Transaction คือ การกระจายการจัดการทรานแซกชั่นไปยังหลายเครื่อง

 

Skin & Gut

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

 

Connect to External Service/Resource

  • Connect to External Service/Resource คือ การเรียกใช้เซอร์วิสหรือทรัพยากรที่อยู่ภายนอกคนละขอบเขตกัน เช่น อยู่คนละเครื่องกัน ควรคำนึงถึง performance และ Coupling โดยไม่ควรให้ระบบมี Coupling กับเทคโนโลยี/แพลตฟอร์ม/ยี่ห้อ/การอิมพลีเม้นต์ของเซอร์วิสหรือทรัพยากรที่เรียก
  • ควรคำนึงถึง Autonomy โดยกำหนดขอบเขตระหว่างกันให้ชัดเจน
  • อิลิเม้นต์ภายในระบบไม่ควรมีสิทธิเรียกเซอร์วิสหรือทรัพยากรภายนอกเองได้ ควรเรียกผ่านตัวกลางทำหน้าที่เรียกใช้ให้ แต่ให้คำนึงถึงรูปแบบเทคนิคการเรียกใช้ที่จะเลือกใช้ อาทิ หากเข้าถึง database server ก็ควรเรียกผ่านตัวกลาง, หากเรียกใช้เซอร์วิสแบบ RESTful service ก็อาจให้อิลิเม้นต์ต่างๆ เรียกเซอร์วิสได้เองโดยไม่ต้องผ่านตัวกลางก็ได้

 

Dispatch & Delegate

  • Dispatch และ Delegate คือ การส่งต่อไปให้โมดูลอื่นหรือส่วนอื่นทำงานต่อหรือทำงานแทน
  • Dispatch และ Delegate มีวัตถุประสงค์เพื่อลดหน้าที่และโอเวอร์เฮดของโมดูลนั้นลง และช่วยกระจายการประมวลผลออกไปยังโมดูลอื่น ทำให้การประมวลผลไม่ได้อยู่ที่จุดเดียว (Single Point of Failure) และช่วยให้เกิดการควบคุมและจัดการ process/flow ได้ดียิ่งขึ้น ส่งผลต่อคุณภาพหลายด้าน เช่น modifiability, performance, availability เป็นต้น

 

Integration & Interoperation

  • Integration คือ การเชื่อมต่อ ที่มุ่งเน้นไปที่ระดับเน็ตเวิร์กมากกว่า อาทิ การเชื่อมต่อระดับโปรโตคอล, เลขพอร์ต หรือในอีกประเด็นหนึ่งคือในแง่การเชื่อมต่อกับระบบหรือทรัพยากรอื่น โดยสนใจไปที่การรับ-ส่งข้อมูลระหว่างกันได้มากกว่าการทำงานร่วมกันได้
  • Interoperation คือ การทำงานร่วมกันได้ โดยปราศจากข้อจำกัดทางระยะทาง, สถานที่, เทคโนโลยี, ภาษาโปรแกรม, แพลตฟอร์ม อาทิ ระบบการเงินที่พัฒนาด้วย Java สามารถทำงานร่วมกับระบบบัญชีที่พัฒนาด้วย C# ได้ ซึ่ง Interoperation มุ่งเน้นไปที่การ call เซอร์วิสหรือเมธอดระหว่างกันมากกว่าแค่การรับ-ส่งข้อมูลกัน
  • การออกแบบการทำงานทั้ง 2 รูปแบบต้องคำนึงถึงคุณภาพสำคัญ อาทิ performance, modifiability, security และแน่นอน integrability กับ interoperability
  • การทำงานทั้ง 2 รูปแบบมักใช้ควบคู่กับ Distribution

 

Discoverability

  • Discoverability คือ ความสามารถในการค้นหาอิลิเม้นต์ที่ต้องการเรียกใช้ ในอีกทางหนึ่งคือความสามารถของอิลิเม้นต์ที่อิลิเม้สต์อื่นสามารถค้นหาตนเองเจอได้ง่ายสะดวก
  • การเรียกใช้อิลิเม้นต์หรือทรัพยากรใดๆ ควรค้นหาเจอได้ง่าย อาจมีตัวกลางทำหน้าที่คนหาและ get reference ให้ได้
  • ในองค์กรขนาดใหญ่ที่มีระบบจำนวนมากควรทำดัชนี (registry) รวบรวมรายการอิลิเม้นต์หรือทรัพยากรต่างๆ อาทิ เซอร์วิส, ข้อมูล, ลอจิก, business rule, เอกสาร, ไลบรารี่, คอมโพเน้นต์ ฯลฯ เพื่อให้นำไปใช้ (reuse) ได้ง่าย ลดความซ้ำซ้อนในการสร้างใหม่โดยไม่ทราบว่ามีอยู่แล้ว
  • กรณีเซอร์วิส, สมัยนี้นิยมสร้างเป็น API สำหรับเซอร์วิสนั้นๆ โดยมีการรวบรวม API ทั้งหมดและจัดการเป็นอย่างดี เพื่อให้พัฒนาอิลิเม้นต์อื่นมาเรียกใช้ได้ง่าย

 

Autonomy

  • Autonomy คือ สิทธิหรืออำนาจในการทำสิ่งใดๆ ได้ด้วยตนเองภายในขอบเขตของตนเอง อาทิ การเชื่อมต่อ database server ได้เองโดยไม่ต้องผ่านตัวกลาง
  • หากอิลิเม้นต์ใดๆ มีระดับ Autonomy สูงเกินไปอาจทำให้เกิด High Cohesion ซึ่งมี Coupling ที่ต่ำเกินไป (low) หรือ lose เลย ทำให้อาจเกิดการทำงานบางอย่างซ้ำซ้อนกับอิลิเม้นต์อื่นได้ และอาจทำให้มีขนาดใหญ่
  • หากอิลิเม้นต์ใดๆ มีระดับ Autonomy ต่ำเกินไปก็จะมี Coupling กับอิลิเม้นต์อื่นมาก ทำให้ไม่ยืดหยุ่นมีระดับ Reusability ต่ำ ยกเว้นเป็นการมี Coupling กับอิลิเม้นต์อื่นผ่านตัวกลาง ไม่ได้มีความสัมพันธ์กันตรงๆ
  • หากอิลิเม้นต์ใดๆ มีระดับ Autonomy ที่พอดี จะช่วยให้มีเสถียรภาพ (stability) ที่ดีอีกด้วย เพราะมีระดับ Coupling ที่ไม่มากหรือน้อยเกินไป

 

Single Point of Failure, Fault Handling, Fault Tolerance

  • Single Point of Failure คือ อิลิเม้นต์ที่มีเพียง instance เดียว หากเกิดข้อผิดพลาดขึ้น อาทิ crash อาจทำให้โฟลว์ของระบบหยุดได้ ดังนั้นจึงมักต้องมีการสร้างตัวสำรองขึ้นเพื่อสนับสนุนด้าน availability หรือหากสนใจด้าน performance ก็ใช้การ copy หรือ clone เพื่อกระจายโหลด
  • Single Point of Failure มักใช้กับจุดสำคัญอย่างจุดเชื่อมต่อระหว่างโฟลว์ภายในระบบ อาทิ front controller, data access object, proxy, remote facade หรือกรณีฮาร์ดแวร์ อาทิ load balancer, router เป็นต้น
  • Fault Handling คือ การจัดการกับข้อผิดพลาดเพื่อให้รับมือหากมีข้อผิดพลาดเกิดขึ้น โดยระบบไม่หยุดชะงักหรือไม่ส่งผลเสียหายต่อไคลเอ็นต์
  • Fault Tolerance คือ ความต้านทานต่อการล้มเหลวเสียหาย โดยการออกแบบระบบที่ต้องมีความแข็งแกร่งสูง ไม่ล่มไม่หยุดชะงักง่าย หรือเมื่อถูกโจมตีหรือแฮ็กแล้ว ก็ไม่ล่มง่ายๆ หรือเมื่อมีปริมาณโหลดเพิ่มขึ้นจำนวนมากก็สามารถประมวลผลไหวโดยระบบไม่ช้าเกินไปหรือล่ม การจัดการจึงมักใช้เทคนิคผสมผสานกันทั้งด้านซอต์ฟแวร์, ฮาร์ดแวร์ และเน็ตเวิร์ก

 

State Machine

  • State Machine คือ กลไกทำหน้าที่จัดการสถานะของอิลิเม้นต์ที่มี state เปลี่ยนไปมาซึ่งการเปลี่ยนไปมานี้มีความสำคัญต่อระบบ อาทิ state ของ user session, transaction session, เซอร์วิส เป็นต้น
  • State คือ สภาวะ ณ ช่วงเวลาหนึ่งของอิลิเม้นต์หนึ่งๆ ที่ประกอบด้วยสถานะ state ซึ่งมีปัจจัยเกี่ยวข้องกับ state เช่น ข้อมูล, เวลา, storage, event, state transition เป็นต้น
  • State Transition คือ การเปลี่ยนสถานะจากสถานะหนึ่งสู่อีกสถานะหนึ่ง ซึ่งอาจเปลี่ยนโดยอัตโนมัติ หรือมีการกระตุ้นจากภายนอก เช่น เมื่อผู้ใช้ submit แบบฟอร์มบนหน้าจอ จึงมีทรานแซกชั่นเกิดขึ้น และ state ของทรานแซกชั่นก็ถูกสร้างและเปลี่ยนไปเรื่อยๆ ระหว่างที่ทรานแซกชั่นทำงานคืบหน้าไปเรื่อยๆ
  • State มีความสัมพันธ์เกี่ยวข้องกับ Granularity อย่างมาก ดังนั้นจึงมีผลต่อ performance มาก และ State ของอิลิเม้นต์ใดๆ มักอยู่ในหน่วยความจำ
  • ดังนั้นหากในระบบที่ออกแบบมีอิลิเม้นต์ที่มี State ที่เปลี่ยนแปลงบ่อย จึงควรมี State Machine มาช่วยจัดการ State ให้

 

Concurrently Access

  • Concurrently Access คือ การมีหลายอิลิเม้นต์เข้าถึงทรัพยากรเดียวกัน (shared resource) พร้อมกัน (simultaneous access) ทำให้เกิดการแย่งกันเกี่ยงกัน (resource contention) จึงต้องมีการเข้าจังหวะสลับกันเข้าใช้ (synchronization) โดยใครจะได้เข้าใช้ก่อนนั้นจึงต้องมีการตัดสินพิจารณา (resource arbitration) ด้วยการจัดตารางการเข้า-ออก (scheduling) เพื่อให้ทุกอิลิเม้นต์เข้าจังหวะสลับกันเข้าใช้ทรัพยากรโดยไม่ชนกันอันอาจเกิด ‘dead lock’
  • การทำ scheduling มีหลายรูปแบบ อาทิ first-in/first-out, priority เป็นต้น
  • หากในงานออกแบบมีอิลิเม้นต์หรือทรัพยากรใดที่มีอิลิเม้นต์ต้องเรียกใช้พร้อมกันจำนวนมาก ต้องจัดการประเด็นต่างๆ ข้างต้นให้ดี
  • หากในงานออกแบบมี process ใดที่เป็นการทำงานแบบไล่ลำดับไปทีละขั้นตอน (sequential) หรือมีทรัพยากรใดที่ก่อนหน้าได้กำหนดให้เข้าถึงแบบทีละหนึ่งอิลิเม้นต์ หากต้องการเพิ่ม performance อาจพิจารณาให้เข้าถึงแบบ Concurrently Access แทน เพราะ Concurrently Access  ยังเหมาะกับงานลักษณะ parallel processing มากๆ

 

Divide and Conquer

  • Divide and Conquer คือ การแตกปัญหาใหญ่ออกเป็นปัญหาย่อยๆ (problem decomposition) โดยแต่ละปัญหาย่อยก็อาจแตกเป็นปัญหาย่อยๆ ไปได้เรื่อยๆ อีก ซึ่งโครงสร้างของปัญหาทั้งหมดเป็นแบบ tree หรือแบบลำดับขั้น (hierarchy) นั่นเอง
  • วัตถุประสงค์ของ Divide and Conquer คือ เพื่อแยกปัญหาใหญ่ออกเป็นปัญหาเล็กๆ แล้วกระจายปัญหาเหล่านั้นออกไปให้อิลิเม้นต์ต่างๆ ช่วยแก้ปัญหาไปพร้อมๆ กัน จนเป็น parallel processing การทำงานเป็นแบบ Recursive เมื่อปัญหาเล็กๆ ระดับล่างแก้ไขเสร็จแล้วจะรวบรวมขึ้นมาระดับบนเรื่อยๆ ซึ่งเป็นลักษณะเดียวกันกับเทคนิค ‘Map-Reduce’ ที่ Google ใช้ในการ search ข้อมูล
  • Divide and Conquer มีรากเหง้าทางความคิดมาจากยุทธวิธีการรบในสมัยก่อนโดยแยกทัพขนาดใหญ่ที่แข็งแกร่งของข้าศึกออกเป็นส่วนๆ เพราะเมื่อถูกแยกแล้วแต่ละทัพย่อยก็จะมีความอ่อนแอลงไม่เหมือนตอนรวมกัน จากนั้นจึงแยกกันไปตีทัพย่อยเหล่านั้น ในบางกรณีเป็นการแยกทัพเพื่อบุกเข้าตีทัพย่อยข้าศึกที่เป็นทัพสำคัญเช่นทัพของแม่ทัพ คล้ายกับการแยกปัญหาเล็กๆ น้อยๆ ที่ไม่ใช่สาระสำคัญนักออกไป แล้วรีบมุ่งแก้ที่แก่นของปัญหา เปรียบดังการแยกปัญหาแล้วกำหนดระดับ priority โดยอิลิเม้นต์ที่ทำงานก็มี priority ที่แตกต่างกันออกไปให้เหมาะสมกับ priority ของปัญหา

 

Messaging

  • Messaging คือ การรับ-ส่งข้อมูลระหว่างกันโดยใช้รูปแบบข้อความ (message) ซึ่งเป็นเทคนิคที่มีใช้มานานแล้ว มีข้อดีคือเรียบง่าย ไม่ซับซ้อน เป็นการทำงานที่ระดับ low level มากๆ นั่นคือที่ระดับเน็ตเวิร์กหรือใกล้เคียงระดับเน็ตเวิร์ก จึงมี performance ดี และยังมีความยืดหยุ่น เป็นเทคนิคที่กำลังกลับมาเป็นที่นิยมอีกครั้ง คล้ายดังสูงสุดคืนสู่สามัญ
  • Synchronous Messaging คือ การรับ-ส่ง message แบบมีการเข้าจังหวะประสานงานกันระหว่างผู้รับและผู้ส่ง โดยผู้ส่งเมื่อส่ง message ออกไปแล้วจะต้องรอให้ผู้รับได้รับ message ก่อน จากนั้นอิลิเม้นต์ที่เป็นผู้ส่งจึงจะไปประมวลผลขั้นตอนลำดับถัดไปต่อได้
  • Asynchronous Messaging คือ การรับ-ส่ง message แบบไม่ต้องเข้าจังหวะประสานงานกันระหว่างผู้รับและผู้ส่ง โดยผู้ส่งต้องส่ง message ออกไปยังอิลิเม้นต์ที่ทำหน้าที่เป็นตัวกลางแล้ว เมื่อตัวกลางได้รับ message แล้วอิลิเม้นต์ที่เป็นผู้ส่งจึงจะไปประมวลผลขั้นตอนลำดับถัดไปต่อได้ จากนั้นตัวกลางจึงค่อยส่ง message นั้นต่อไปยังอิลิเม้นต์ที่เป็นผู้รับต่อไป Asynchronous Messaging เป็นการทำงานที่มีความน่าเชื่อถือ (reliability) สูง ทั้งยังมี performance ที่ดี มี Coupling ต่ำ
  • Message Routing คือ การมีตัวกลางทำหน้าที่รับและส่งต่อ message โดยอิลิเม้นต์ต่างๆ ไม่ต้องรับ-ส่งกันเองโดยตรง ใช้ได้กับ Messaging ทั้ง 2 แบบ

 

Persistence

  • Persistence คือ การจัดเก็บข้อมูลไม่ให้สูญหาย อาทิ การเก็บเป็นไฟล์, การเก็บลง database
  • การออกแบบการจัดเก็บข้อมูลจึงต้องพิจารณาเลือก ‘persistent storage’ ให้เหมาะสมกับรูปแบบอิลิเม้นต์ที่จะเก็บ และยังต้องเลือกรูปแบบการเข้าถึงให้เหมาะสมเช่นกัน รวมถึงพิจารณาการจัดการคุณภาพที่เกี่ยวข้องให้ดี

 

Information Exchange

  • Information Exchange คือ การแลกเปลี่ยนข้อมูลระหว่างอิลิเม้นต์
  • หากข้อมูลมี format ที่ตรงกันทั้งผู้รับและผู้ส่งก็ถือว่าโชคดีไม่มีอุปสรรค แต่หากไม่ตรงกันจำเป็นต้องมีการ transform หรือ convert หรือทำ mapping กัน ก็จะเกิดโอเวอร์เฮดได้
  • ควรมีการกำหนด format และไวยากรณ์ของข้อมูลที่ใช้รับ-ส่งกันให้ดี จะช่วยให้มีมาตรฐาน ทำงานร่วมกันได้ง่าย ลดความซับซ้อนและซ้ำซ้อน
  • ข้อมูลที่รับ-ส่งกัน ต้องออกแบบคำนึงถึง Granularity ด้วยเสมอ

 

Configuration & Customization

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

 

Authentication & Authorization

  • Authentication คือการพิสูจน์ตัวตน (identification) ของไคลเอ็นต์ที่ต้องการเข้าสู่ระบบหรือต้องการเรียกใช้อิลิเม้นต์ อาทิ โดยทั่วไปตรวจสอบจาก username กับ password ซึ่งอาจตรวจสอบรายละเอียดอื่นอีกได้ อาทิ หมายเลข IP address ควรเลือกใช้เทคนิคที่เป็นมาตรฐาน การออกแบบควรตรวจสอบโดยคำนึงถึงระดับความปลอดภัยที่ต้องการ
  • Authorization คือ การพิสูจน์สิทธิของไคลเอ็นต์ที่ต้องการเข้าถึงอิลิเม้นต์ อาทิ ฟังก์ชั่น, หน้าจอ, เมนู, ปุ่ม, เซอร์วิส เป็นต้น การตรวจสอบสิทธิทำได้หลายวิธีการ อาทิ ตรวจสอบประเภทไคลเอ็นต์, group, role หรือพารามิเตอร์อื่นๆ ที่ส่งมาพร้อมกับ request
  • ในทางปฏิบัติต้องทำ Authentication ก่อน หากตรวจสอบผ่านแล้วจึงทำ Authorization
  • เทคนิคและมาตรฐานที่เกี่ยวกับ security มีจำนวนมาก ให้พิจารณาให้ดีก่อนตัดสินใจใช้

 

Localization (L10N) & Internalization (I18N)

  • Localization (L10N) คือ การปรับรูปแบบคุณสมบัติหรือการทำงานให้เข้ากับบริบทนั้นๆ
  • Internalization (I18N) คือ การปรับรูปแบบข้อมูลให้เข้ากับภาษาในประเทศนั้นๆ หรือตามที่ผู้ใช้ต้องการ อาทิ ตัวอักษร, วันที่, จำนวนตัวเลข เพราะแต่ละประเทศอาจมีการใช้ตัวอักษร, วันที่, จำนวนตัวเลข ที่แตกต่างกันได้นั่นเอง
  • ข้อมูลหรือการทำงานส่วนใดที่ต้องปรับให้เข้ากับบริบทหรือผู้ใช้จึงควรพิจารณาเลือกใช้ L10N กับ I18N

 

Sensitivity & Trade-Off

  • Sensitivity คือ การที่อิลิเม้นต์สามารถที่จะอ่อนไหวต่อการเปลี่ยนแปลงใดๆ ที่อาจเกิดขึ้นจากภายในหรือภายนอก (คล้ายคนเป็นโรคภูมิแพ้อากาศ เมื่ออากาศเป็นปกติก็ไม่เป็นอะไร แต่เมื่ออากาศเปลี่ยนเพียงเล็กน้อยก็อาจไม่สบายได้ง่าย) เมื่อมีการเปลี่ยนแปลงเกิดขึ้นจะส่งผลต่อการทำงานและคุณภาพของอิลิเม้นต์นั้นในทางบวกหรือทางลบได้
  • เมื่อออกแบบระบบไปสักพักแล้วจึงต้องวิเคราะห์อิลิเม้นต์ต่างๆ ที่ออกแบบขึ้นมาว่ามีระดับ Sensitivity มากน้อยแค่ไหน จะได้เลือกจัดการตัวที่มีระดับ Sensitivity สูงๆ ให้ดี
  • Trade-Off คือ การมีทั้งข้อดีและข้อเสียในตัว อาทิ โซลูชั่นใดๆ ที่สามารถแก้ปัญหาหนึ่งๆ ได้ ก็อาจก่อให้เกิดผลกระทบเชิงลบในด้านอื่นได้เช่นกัน
  • การพิจารณาเลือกโซลูชั่นใดมาใช้จึงควรกำหนดให้มี candidate solution แล้วค่อยคัดเลือกตัวที่เหมาะสม ส่งผลกระทบข้างเคียงน้อย
  • ทั้ง Sensitivity และ Trade-Off สามารถก่อให้เกิดความเสี่ยง ณ จุดนั้นๆ ได้ จึงต้องวิเคราะห์ความเสี่ยงและวิเคราะห์ผลกระทบให้ดี ก่อนตัดสินใจเลือกใช้โซลูชั่นใดๆ ก็ตาม
Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s