อิฐก้อนเล็กที่สุดใน Software Architecture

สวัสดีครับ,

ก็วันนี้จะพูดเรื่องที่น่าจะมีคนสนใจหลายคน

นั่นก็คือ Software Architecture นั่นเอง

.

ซึ่งคำว่า Software Architecture นั้น

หลายครั้งที่ใช้เป็น คำใหญ่

หลายครั้งที่ใช้แล้วมันเป็น Black Box

ซึ่งที่ผมจะสื่อก็คือ เราไม่สามารถตีความออกมาได้ว่า

Software Architecture นั้นคืออะไร

แล้วจริงๆ มันทำงานกันอย่างไร เพื่ออะไร

.

สุดท้าย ถ้าคำนี้กลายเป็น Black Box

พอเวลาอะไรมีปัญหา ซึ่งดูแล้วมันซับซ้อน

ก็จะโยนใส่คำว่า “Architecture” ไว้ก่อน

เพราะมันเป็น Black Box ซึ่งทุกคน Safe

เพราะไม่มีหน่วยงานไหนรับผิดชอบ Architecture ชัดเจนมาก ในแต่ละองค์กร

ถึงจะมีหน่วยงานชื่อ Enterprise Architecture ก็เหอะ

แต่นั่นก็จะบอกว่าเค้าดู RoadMap และ Strategy ไม่ได้ดูเรื่อง Implementation

.

ดังนั้น ผมจึงชอบเปรียบเปรย การใช้คำว่า Architecture

ในองค์กรต่างๆ ว่า เป็นคำใหญ่บ้าง เป็น Black Box บ้าง

เพราะฟังแล้วรู้สึกซับซ้อน จนไม่มีใครกล้าเข้าไปแก้ไขมัน

(เพราะไม่มีผู้รับผิดชอบกลาง และถึงมีก็มีท่าปัดหลายท่า)

.

จริงๆ Architecture ก็เหมือน UX ในแง่นึงแหละครับ

นั่นคือ เป็นความรับผิดชอบร่วมกันของทั้งองค์กร

ไม่ใช่หน่วยงานใดหน่วยงานนึงในองค์กร

และถึงมีหน่วยงานนั้นอยู่ มันก็ไม่ได้แปลว่า

ความรับผิดชอบทั้งหมด จะตกที่หน่วยงานนั้น

.

เพราะอะไรนะเหรอครับ???

เพราะ Architecture แปลว่า “How the things Work”

(ผมชอบใช้คำอธิบายนี้นะ ตามลุง Robert C. Martin แก)

ซึ่งแปลเป็นไทยว่า “ทุกสิ่งทุกอย่างทำงานร่วมกันอย่างไร”

ถ้าเราใช้คำว่า ทุกสิ่งทุกอย่าง แล้ว ก็แปลว่าทุกคนมีส่วนเกี่ยวข้อง

ดังนั้น มันไม่ใช่เรื่องของใครคนใดคนนึง หรือหน่วยงานใดหน่วยงานนึงหรอกครับ

.

ถ้าแปลห้วนๆ ว่า How the things Work มันจะมองไม่เห็นภาพ

ผมก็ชอบคำอธิบาย ที่พี่คริสแกใช้ เวลาสอนเด็กๆเรื่องเขียน code

(ฟังมาจาก After Party งาน Software Architect MeetUp Bangkok#1)

.

พี่คริส: รู้มั้ย Software Architecture คืออะไร?

พวกเด็กๆ: (ทำหน้างงๆ)

พี่คริส: เวลาพวกนายเขียน code ร่วมกันอ่ะ แล้วเจอ requirement มา พวกนายรู้มั้ยว่า requirement นั้นๆ ถ้าจะทำให้เสร็จ ต้องใส่ลงตรงไหนของ code บ้าง?

พี่คริส: ถ้าพวกนายรู้ ก็แปลว่า นายเข้าใจโครงสร้างของ code ใน Project นาย ซึ่งทำให้นายและเพื่อนๆในโปรเจ็คทำงานร่วมกันได้ นั่นแหละ Software Architecture

(คำพูดอาจจะไม่ตรงทุกประโยคที่พี่คริสแกพูดนะ แต่ใจความเป็นแบบนี้)

.

พูดง่ายๆว่า Architecture คือโครงสร้างที่ทุกคนตกลงจะทำร่วมกันนั่นแหละ

หรืออธิบายอย่างลุงมาตินก็ได้ว่า ทุกสิ่งทุกอย่างทำงานร่วมกันยังไง

.

ทีนี้ พอเราเอาคำว่า Architecture มาขยายด้วยคำว่า Software

มันก็จะแปลว่า โครงสร้างของ Software ที่ทุกคนเห็นร่วมกันนั้นคืออะไร

.

แต่พอคำว่า Software มันเป็นคำกว้างงงงงงงงงงงงงงงงง

มันเลยสามารถบอกได้ตั้งแต่ Software Architecture ในระดับ Project

เช่น Model-View-Controller

หรือแม้นกระทั่ง Software Architecture ในระดับองค์กร

CRM -> Internet Banking -> Service Bus -> Core Bank -> ERP (Accounting)

อะไรประมาณนี้

ดังนั้น การใช้คำว่า Software Architecture จึงต้องดูบริบทแวดล้อมดีๆ

ว่าอยู่ใน Abstraction Level ระดับไหน

.

อย่างไรก็แล้วแต่ ไม่ว่า Abstraction Level ระดับไหนก็ตาม

มันจะมีสิ่งนึงที่สำคัญที่สุดใน Software Architecture

นั้นก็คือ Definition ของสิ่งต่างๆ นั่นเอง

.

ทวนกลับนะครับ

“Software Architecture คือการเข้าใจว่าทุกสิ่งทำงานร่วมกันอย่างไร”

ดังนั้นคำว่า “ทุกสิ่ง” แมร่งมีอะไรบ้างก่อน

แล้วทุกคนเข้าใจ แต่ละสิ่ง ในคำว่าทุกสิ่งนั้นตรงกันมั้ย

แล้วนี่แหละครับคือ “อิฐก้อนแรก” ของ Software Architecture

.

ถ้ามอง Software Architecture เป็น บ้าน เป็นเมือง เป็นจังหวัด เป็นประเทศ

แน่นอนครับ ส่วนใหญ่ที่เราใช้ในการก่อนสร้างสิ่งต่างๆคือ ก้อนอิฐ

ดังนั้น ก้อนอิฐ ในเรื่อง Software Architecture ก็คือ Definition นั้นเอง

(ศัพท์เทคนิคเข้าจะใช้คำว่า Building Block แทนก้อนอิฐนะครับ)

หรือพูดใช้ชัดง่ายๆว่า ก้อนอิฐของ Software Architecture ก็คือ “ชื่อตัวแปร” นั่นเอง

.

แล้วชื่อตัวแปรนั้นสำคัญอย่างไร?

“Architecture คือทุกสิ่งทุกอย่างทำงานร่วมกันอย่างไร”

“ก่อนที่จะทำงานร่วมกันนั้น ต้องเข้าใจสิ่งต่างๆร่วมกันก่อน ว่าแต่ละสิ่งคืออะไร”

ก็นั่นแหละครับ ต้องเข้าใจร่วมกันก่อน

.

อย่างเช่นที่ Billme แน่นอนครับเราเป็นบริษัทส่งบิล

ดังนั้น ก้อนอิฐก้อนหนึ่งที่เราใช้ประจำคือคำว่า Bill

แต่โลกความเป็นจริงก็โหดร้ายนัก คำว่า Bill มีคำคล้ายๆคือ Invoice

และคำว่า Bill มันก็แปลได้หลายบริบทหลายความหมาย

ในบาง domain specific ของบ้านเรา คำว่าบิลแมร่งเสือกหมายถึง ใบเสร็จ …

.

ดังนั้นการจะสร้างทุกอย่างได้ใน Software Architecture ของ Billme

เราต้องนิยามให้ชัดก่อนว่า Bill คืออะไร, Invoice คืออะไร, Receipt คืออะไร

.

เรื่องของบิล ก็มีหลากหลายรูปแบบ เช่น สร้าง, จัดส่ง, ยอมรับบิล (มีสถานะเป็นหนี้), จ่ายบิล, ยืนยันการได้รับเงิน, ออกใบเสร็จ, จัดส่งใบเสร็จ, …

ดังนั้นก้อนอิฐที่เราจะใช้ส่งบิล ก็มีลักษณะแตกต่างกันไป

.

พอผมเอาเรื่องของการส่งบิล มา map ลง Software Architecture ของ Billme

ก็จะได้ภาพประมาณด้านล่างนี้

แต่ในภาพนี้เรายังเห็นแค่ Business Process & Business Logic คร่าวๆ

ที่แต่ละตัวทำงานกันอยู่ มันยังต้องเพิ่มก้อนอิฐเข้าไปอีก

.

แต่ก้อนอิฐที่จะเพิ่มเข้าไปนี้ เป็นก้อนอิฐเชิงเทคนิคแล้ว

เพราะ Business Process มันดู Flow กันเรียบร้อยแล้ว

ผมจะลองเพิ่มเข้าไปให้ดูประมาณนี้

พอเป็นภาพนี้ เราจะเริ่มเห็นก้อนอิฐของเรามากขึ้น

แน่นอนก้อนอิฐพวกนี้เป็นโครงสร้างสำหรับทำอะไรซักอย่าง

ซึ่งก้อนอิฐพวกนี้ต้องถูกแต่งแต้มสีด้วย Business Logic

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

.

แล้วนี่แหละครับคือ ก้อนอิฐที่เล็กที่สุดใน Software Architecture

ซึ่งก็คือ “ชื่อตัวแปร” นั่นเองครับ

.

หรือถ้าจะอธิบายในอีกมุมนึงก็คือ

Architecture นั้นเป็นเรื่องของการกำหนด Abstraction Layer

ซึ่ง Abstraction Layer ที่เล็กที่สุดในมุม Software

นั้นก็คือ “ชื่อตัวแปร” นั่นเองแหละครับ

.

สวัสดีครับ.

.