Use Layers Semantically, Not Decoratively (ใช้เลเยอร์อย่างมีความหมาย ไม่ใช่แค่ตกแต่ง)

เราชอบเครื่องมือวาดภาพที่รองรับเลเยอร์ แต่เราขอแนะนำให้ใช้มันอย่าง มีความหมาย (semantically) นั่นคือใช้ในแบบที่เพิ่มความหมายให้กับภาพรวมทั้งหมด ตัวอย่างเช่น เลเยอร์ฐาน (base layer) ของแต่ละไดอะแกรมควรแสดงโครงสร้างของสถาปัตยกรรม ได้แก่ คอนเทนเนอร์ (container) ฐานข้อมูล ดีเพนเดนซี (dependency) โบรกเกอร์ (broker) และองค์ประกอบหลักอื่นๆ เลเยอร์นี้ควรเน้นที่สถาปัตยกรรมมากกว่ารายละเอียดการอิมพลีเมนต์ เช่น ให้ระบุว่า "การสื่อสารแบบซิงโครนัส" แทนที่จะระบุโปรโตคอลที่เจาะจง ส่วนเลเยอร์ถัดไปควรมีรายละเอียดการอิมพลีเมนต์ เช่น ใช้ฐานข้อมูลชนิดใด ใช้โปรโตคอลการสื่อสารแบบไหน เป็นต้น

การใช้เลเยอร์ในลักษณะนี้ทำให้ไดอะแกรมขยายต่อได้ง่าย (extensible) สามารถเพิ่มเลเยอร์อื่นๆ ที่มีบริบทเฉพาะเพื่อนำเสนอขอบเขตของ domain-driven design ขอบเขตของทรานแซกชัน หรือข้อมูลเมตาอื่นๆ ที่สถาปนิกต้องการเปรียบเทียบกับโครงสร้างของสถาปัตยกรรม

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

Diagramming Standards: UML, C4, and ArchiMate (มาตรฐานการเขียนไดอะแกรม: UML, C4 และ ArchiMate)

อุตสาหกรรมซอฟต์แวร์ใช้มาตรฐานที่เป็นทางการหลายแบบสำหรับไดอะแกรมทางเทคนิค เราจะมาดูสามมาตรฐานที่ได้รับความนิยมมากที่สุดกันในที่นี้

UML

Grady Booch, Ivar Jacobson และ Jim Rumbaugh สร้างมาตรฐาน Unified Modeling Language (UML) ขึ้นในทศวรรษ 1980 เพื่อรวมแนวคิดการออกแบบที่แข่งขันกันของทั้งสามคนเข้าด้วยกัน มันควรจะเป็นสิ่งที่ดีที่สุดของทุกฝ่าย แต่เหมือนกับหลายๆ สิ่งที่ถูกออกแบบโดยคณะกรรมการ มันกลับไม่สร้างผลกระทบมากนักนอกองค์กรที่บังคับให้ใช้ สถาปนิกและนักพัฒนายังคงใช้ไดอะแกรม UML แบบ class และ sequence เพื่อสื่อสารโครงสร้างและ workflow อยู่ แต่ไดอะแกรม UML ประเภทอื่นๆ ส่วนใหญ่ก็เลิกใช้กันไปแล้ว

C4

C4 เป็นเทคนิคการเขียนไดอะแกรมที่พัฒนาโดย Simon Brown ระหว่างปี 2006 ถึง 2011 เพื่อแก้ไขข้อบกพร่องของ UML และปรับแนวทางให้ทันสมัยขึ้น "four Cs" ใน C4 ได้แก่:

Context (บริบท)

บริบททั้งหมดของระบบ รวมถึงบทบาทของผู้ใช้และดีเพนเดนซีภายนอก

Container (คอนเทนเนอร์)

ขอบเขตการดีพลอยทางกายภาพ (และมักรวมถึงทางตรรกะ) และคอนเทนเนอร์ต่างๆ ภายในสถาปัตยกรรม มุมมองนี้เป็นจุดร่วมที่ดีระหว่างทีม operations และสถาปนิก

Component (คอมโพเนนต์)

มุมมองระดับคอมโพเนนต์ของระบบ ซึ่งสอดคล้องกับมุมมองของสถาปนิกที่มีต่อระบบมากที่สุด

Class (คลาส)

C4 ใช้รูปแบบไดอะแกรมคลาสแบบเดียวกับ UML ซึ่งมีประสิทธิภาพอยู่แล้ว จึงไม่จำเป็นต้องเปลี่ยนไปใช้แบบอื่น

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

ไดอะแกรม C4 ของการออกแบบข้อมูลแบบ modular monolith ของ Silicon Sandwiches ปรากฏอยู่ใน Figure 23-2 .

Figure 23-2. ไดอะแกรมคอมโพเนนต์ของ Silicon Sandwiches ในรูปแบบ C4

ArchiMate

ArchiMate (คำผสมระหว่างคำว่า architecture และ animate ) เป็นภาษาสร้างแบบจำลองสถาปัตยกรรมองค์กร (enterprise-architecture) แบบโอเพนซอร์สจาก The Open Group สำหรับอธิบาย วิเคราะห์ และแสดงภาพสถาปัตยกรรมทั้งภายในและข้ามโดเมนธุรกิจ ArchiMate มอบภาษาสร้างแบบจำลองที่เบากว่าสำหรับระบบนิเวศระดับองค์กร เป้าหมายของมาตรฐานทางเทคนิคนี้คือการ "เล็กที่สุดเท่าที่จะเป็นไปได้" ไม่ใช่การครอบคลุมทุกกรณีปลีกย่อย มันเป็นตัวเลือกที่ได้รับความนิยมในหมู่สถาปนิก

Diagram Guidelines (แนวทางการเขียนไดอะแกรม)

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

Titles (ชื่อกำกับ)

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

Lines (เส้น)

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

หนึ่งในมาตรฐานทั่วไปไม่กี่ข้อของไดอะแกรมสถาปัตยกรรมคือ เส้นทึบมักหมายถึงการสื่อสารแบบซิงโครนัสเสมอ ส่วนเส้นประหมายถึงการสื่อสารแบบอะซิงโครนัส

Shapes (รูปทรง)

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

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

Labels (ป้ายกำกับ)

การใส่ป้ายกำกับให้กับทุกไอเทมในไดอะแกรมเป็นสิ่งสำคัญ โดยเฉพาะถ้ามีโอกาสที่จะเกิดความคลุมเครือ

Color (สี)

สถาปนิกมักใช้สีน้อยเกินไป เพราะเป็นเวลาหลายปีที่หนังสือจำเป็นต้องพิมพ์เป็นขาวดำ ทำให้สถาปนิกและนักพัฒนาคุ้นเคยกับภาพวาดโทนสีเดียว แม้เราจะยังชอบโทนสีเดียวอยู่ แต่เราก็ใช้สีเมื่อมันช่วยแยกความแตกต่างระหว่างอาร์ติแฟกต์ได้ ตัวอย่างเช่น ตอนพูดถึง microservices architecture quantum ใน Chapter 19 เราใช้เฉดสีเทาใน Figure 19-6 (ซึ่งนำมาแสดงซ้ำที่นี่เป็น Figure 23-3 ) เพื่อบอกการจัดกลุ่ม

Figure 23-3. การแสดงซ้ำตัวอย่างการสื่อสารของไมโครเซอร์วิสจาก Chapter 19 โดยแสดงเซอร์วิสต่างๆ ด้วยเฉดสีเทาที่แตกต่างกัน

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

Keys (คีย์อธิบายสัญลักษณ์)

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