-
หลักการในการพัฒนา modern app นั้นมีค่อนข้างหลากหลาย และถูกใช้ในแบบที่แตกต่างกันในแต่ละที่ แต่ละสภาพแวดล้อมของ App และทีม Development ส่วนตัวชอบ process การออกแบบโดยใช้ Swift เพราะเป็นวิธีการที่ prove แล้วว่าใช้ได้จริงในองค์กรใหญ่ๆ โดยใช้ concept DDD และมีขั้นตอนคร่าวๆ ดังนี้ สรุปรูปแบบข้างต้นจากบนลงล่าง
-
หลังจากที่ได้เรียนรู้ Domain Driven Design (DDD) แล้ว ลองเอา concept ของ DDD มาใช้เพื่อออกแบบ Software Architect โดยใช้หลักการของ Swift Method ซึ่งเป็น framework สำหรับการพัฒนา Modernization Software เริ่มจากสิ่งที่เราเข้าใจ และอธิบายความหมายของคำว่า Item อย่างไร Item สำหรับแต่ละคนมีความหมายที่แตกต่างกัน แล้วแต่ประสบการณ์และมุมมอง Item เมื่อไปอยู่ในแต่ละ context ที่แตกต่างกัน ก็จะมีลักษณะไม่เหมือนกัน หรือเป็นคนละอย่างกันเลย เช่น Item ที่อยู่ใน Cart ก็อาจจะเป็นสินค้า แต่ Item ที่อยู่ใน Order ก็จะหมายถึงคำสั่งซื้อ โดยที่อาจจะมีข้อมูลและลักษณะใช้แทนกันไม่ได้เลยทีเดียว ดังนั้นการออกแบบ Software ที่หลายๆ Application ใช้ share data model เดียวกันจึงเป็นการออกแบบที่ไม่เหมาะสม เพราะจะมีปัญหาเรื่องของการ
-
หลักการพิจารณาเพื่อให้การออกแบบ Application สามารถทำงานบน Cloud Environment ได้อย่างราบรื่น และใช้ความสามารถของ Cloud ใด้อย่างมีประสิทธิภาพ ประกอบด้วย 12 ข้อดังนี้ 2. Dependencies ระบุความต้องการ lib และ dependencies อื่นๆ ใน project และไม่ share 3. Configuration เก็บ configuration ของ application ใน environment ของระบบ แยกจาก code 4. Backing services สร้าง resource adapter ไปยัง external service อื่นๆ โดยมองว่าเป็นหนึ่ง resource ที่ application เรียกใช้งาน ทำให้การสลับแต่ล่ะ resource ทำได้ด้วยการ attach resource ใหม่
-
เป็นรูปแบบการออกแบบ Software System ที่แก้ปัญหาความซับซ้อน (complexity) โดยเทียบเคียงกับหน่วยงานหรือองค์กรที่การดำเนินงานธุรกิจ ที่มีความถนัดในเรื่องใดเรื่องหนึ่งเฉพาะ (expert domain) การใช้วิธีการนี้เป็นการนำไปสู่การออกแบบ microservice application ได้อย่างดีรวมถึงเป็นการสื่อสาร สร้างความเข้าใจกับทีม Business อย่างมีประสิทธิภาพ (Business first approach) Domain Driven design แบ่งออกเป็น 2 ส่วนคือ Strategic design และ Tractical Design โดยที่ Strategic Design เป็นการออกแบบเชิงกลยุทธ์ เน้นถึงสิ่งที่สำคัญเชิงกลยุทธ์ต่อธุรกิจ โดยแบ่งตามความสำคัญและผสมผสานตามความจำเป็น Strategic Domain Driven Design ประกอบด้วย Tactical Domain Driven Design เป็นวิธีปฏิบัตที่จะทำให้บรรลุเป้าหมายตามกลยุทธ์ ส่วนนี้จะลงลึกถึงขั้นตอนในเชิงปฏิบัติ ประกอบด้วย Domains ประกอบด้วย sub-domains และ bounded context Core
-
ลักษณะของ software architecture ที่รวมทุก modules ไว้ใน project หรือ package เดียว เพื่อความง่ายในการเรียกใช้ function หรือ service ใน project โดยไม่ต้องแยก deploy ที่ต้องเรียกใช้งานผ่าน interface อย่างเช่น API อีกทั้งการส่งมอบงาน และ deploy ก็ง่ายเพราะ deploy ทั้ง package และการ reuse ในส่วนของ code ก็ทำได้สะดวกสบาย ถือเป็นหลักนิยมของการพัฒนา software ในยุคที่ผ่านมา จนกระทั้ง software ได้ถูกนำมาใช้เป็นบริการหลักของธุรกิจ ความต้องการใหม่ๆ ที่เพิ่มและแก้ไขตลอดเวลา รวมถึงการรองรับจำนวนผู้ใช้จำนวนมาก ทำให้รูปแบบการพัฒนาแบบเดิมเริ่มจะส่งผลในทางลบมากกว่า กล่าวคือ การเพิ่มทีมพัฒนาเข้าไปจะทำได้ยาก เพราะการวาง code ภาษาที่ใช้ จะรู้จักดีในเฉพาะทีมเท่านั้น แต่ละ module ที่มีการเรียกใช้งานเริ่มมีความซับซ้อน และต้อง share
-
Lean Canvas เป็นเครื่องมือที่จะทำให้ Team เข้าใจปัญหาและเลือกแนวทางที่เหมาะสมสำหรับการเปลี่ยนแปลง ด้วยการวิเคราะห์อย่างปัญหารอบด้าน ตัวอย่างนี้จะเป็นการนำ Lean Canvas มาใช้สำหรับการ Change ในกระบวนการพัฒนา Software โดยพิจารณาถึงสิ่งที่องค์กรจะได้รับจากการเปลี่ยนแปลง (Business Outcomes) เริ่มต้นด้วยการกำหนดหัวข้อในรูปแบบตาราง เพื่อให้ผู้ที่เกี่ยวข้องได้เสนอความคิดในรูปแบบ sticky board และหารือกันในแต่ละประเด็นได้ง่าย เพื่อให้ตกผลึก จนเป็นข้อมูลสุดท้ายที่ทุกคนเห็นพ้องกัน Problem Risk Current State Operating Model People Process Technology Metrics Future State Operating Model People Process Technology Business Outcomes Enablers/Partners Costs (Operation efficiency) Revenue (Innovation/Productivity) รายละเอียดในแต่ละแผ่น PROBLEM Risk Current State Operating Model
-
เพื่อให้เข้าใจเรื่อง cloud native เราจะต้องทำความเข้าใจที่มาที่ไปว่าทำไมถึงมี cloud native แล้ว cloud native คืออะไร รวมถึงเราจะสร้าง cloud native ต้องทำอย่างไรบ้าง WHY? เริ่มต้นจากที่เรามี pain เกี่ยวกับ infrastructure ที่ต้องการ scale เพื่อให้รองรับ workload ที่มากขึ้นจาก model ธุรกิจที่ต้องแข่งขัน และการ transform business ให้เป็น digital business ทำให้ infrastructure ไม่สามารถรองรับการเติมโตได้ทัน จึงเป็นโอกาสให้ service provider ต่างๆ ออกมาให้บริการ infrastruture ในแบบ on demand ที่เราคุ้นเคยก็จะเป็นบริการ cloud service ของเจ้าตลาดอย่าง aws , google หรือ azure รวมถึง local
-
กระบวนการในการพิจารณา เพื่อประเมินความเหมาะสมสำหรับการย้าย Application ไปยัง Cloud Native Platform นั้นมี criteria หลายอย่างด้วยกัน ซึ้งบทความนี้จะให้คำแนะนำเพื่อเป็นแนวทางให้สามารถตรวจสอบ Application จัดลำดับความสำคัญ สิ่งที่ต้องปรับเปลี่ยน (refactore) เพื่อทำเป็น backlog ในขั้นตอนของ Implement ต่อไป สำหรับการประเมินนั้น หลักๆ จะใช้หลักการของ 12 Factors ที่เป็นหลักการในการออกแบบ Cloud Native Application ซึ้งสามารถอ่านข้อมูลเพิ่มเติมได้จาก http://12factor.net โดยแต่ละรายการที่จะกล่าวต่อไปในหัวข้อ 12 Factors ที่ส่งผลกระทบกับกระบวนการออกแบบ Application ที่ถ้า Application สามารถ comply ได้ ก็จะจัดได้ว่าเหมาะสมในการย้าย platform (replatform) แต่ถ้ากรณีที่ Factor ที่สำคัญๆ Application ไม่สามารถ comply ได้ก็จะพิจารณาว่าไม่เหมาะสมในการย้าย Application ไปยัง Cloud Native
Tech Notes
Technology is changing over time like the human age, documenting the finding helps me remember my footstep
Tech Notes 