นี่จะเป็นเรื่องราวเกี่ยวกับความประทับใจของฉันต่อหนังสือเล่มนี้ และจะพูดถึงแนวคิดและความรู้บางอย่างที่ได้เรียนรู้จากหนังสือเล่มนี้
สถาปัตยกรรม
โดยการอ่านเอกสารฉบับนี้ คุณสามารถให้คำตอบที่ชัดเจนสำหรับคำถามที่ว่า สถาปัตยกรรมคืออะไร ได้หรือไม่ สถาปัตยกรรมในบริบทของการเขียนโปรแกรมและการออกแบบคืออะไร? เธอมีบทบาทอะไร? มีความคลุมเครือค่อนข้างมากในระยะนี้ และดูเหมือนทุกอย่างจะชัดเจน แต่ก็เป็นนามธรรมและไม่มีความแม่นยำ Martin เชื่อและฉันเห็นด้วยกับเขาว่าแอปพลิเคชันมีสององค์ประกอบ:
- พฤติกรรม - ฟังก์ชั่นและงานที่โปรแกรม (ส่วนประกอบ บริการ) ดำเนินการ
- สถาปัตยกรรม - คำนี้เป็นข้อมูลเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงแอปพลิเคชัน
แต่ถึงแม้ว่าแอปพลิเคชันจะทำงานได้ แต่ก็ควรจะทำงานได้ดีมาก แต่ก็ไม่ได้หมายความว่าแอปพลิเคชันนั้นมีสถาปัตยกรรมที่ดี สถาปัตยกรรมไม่ได้เกี่ยวกับพฤติกรรมของแอปพลิเคชัน สถาปัตยกรรมเป็นเรื่องของความง่ายในการเปลี่ยนแปลง สถาปัตยกรรมเป็นเรื่องของความสะดวกในการใช้งาน สถาปัตยกรรมเป็นเรื่องของความเป็นอิสระของการพัฒนา สถาปัตยกรรมเป็นเรื่องเกี่ยวกับความเร็วที่ความเข้าใจเกิดขึ้นกับคนใหม่ในทีม
และนี่คือวิธีสร้างสถาปัตยกรรมนี้ วิธีกำจัดอาการปวดหัวเมื่อมีการเปลี่ยนแปลงข้อกำหนดเล็กน้อยจาก PM หรือจากผู้มีส่วนได้ส่วนเสีย นี่คือสิ่งที่หนังสือเล่มนี้จะบอกคุณ
เกี่ยวกับผู้แต่ง
ก่อนจะพูดอะไรเกี่ยวกับหนังสือเล่มนี้ ฉันอยากจะพูดถึงตัวเองสักหน่อยก่อน
ในขณะนี้ ฉันเป็น Strong Junior Developer ซึ่งเชี่ยวชาญด้านการพัฒนาบริการโดยใช้ ASP .NET CORE
ฉันทำงานที่ "แกลเลอรี" เดียวกันนี้มาได้หนึ่งปีแล้ว และดูเหมือนว่าฉันจะจัดการได้นิดหน่อย
ฉันอ่านหนังสือเล่มนี้มาแล้ว 2 ครั้ง และฉันแนะนำให้ทุกคน:
- ผู้พัฒนาระบบฝังตัว
- วิศวกรส่วนหน้า
- คนงานส่วนหลัง;
- และแม้กระทั่งการเสียสละ
โดยทั่วไปแล้ว สำหรับทุกคนที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์ในทางใดทางหนึ่ง เราหมายถึงการพัฒนาโดยตรงของฝ่ายขายและ PM ต่างๆ เราไม่ได้คำนึงถึงในที่นี้ (แม้ว่าจะเป็นประโยชน์หากทราบว่าเหตุใดบางครั้งเด็กผู้หญิงจึงใช้เวลา 2 ครั้ง) มีเวลาทำงานมากขึ้น) ฉันแนะนำให้คุณอ่านหนังสือเล่มนี้
และตอนนี้ฉันจะพยายามโต้แย้งว่าทำไมฉันถึงคิดอย่างนั้น
เล็กน้อยเกี่ยวกับผู้แต่งหนังสือเล่มนี้ (เพราะสำหรับฉันอำนาจของนักเขียนมีบทบาทสำคัญ) ฉันคิดว่าคุณจะเข้าใจฉัน แม้ว่าจะไม่ถูกต้องเสมอไป แต่ถ้าผู้มีอำนาจในสาขานี้บอกคุณบางอย่าง คุณจะแสดงความมั่นใจในสิ่งที่เขาพูดมากขึ้น เช่น ฉันคิดว่าคุณจะเชื่อคำวินิจฉัยที่แพทย์ให้มากกว่าเชื่อจากคนในกลุ่ม (ที่ค้นหาอาการใน Google)
Robert Martin หรือที่รู้จักในชื่อ Uncle Bob (ลุง Bob) ทำงานในด้านการเขียนโปรแกรมและระบบต่างๆ (ตั้งแต่บริการเว็บไปจนถึงระบบฝังตัว) ตั้งแต่ปี 1970 เป็นที่ปรึกษาด้านเทคนิคและสถาปนิก เขียนให้กับนิตยสารด้านเทคนิคต่างๆ ตัวเขาเองเป็นโปรแกรมเมอร์ที่มีประสบการณ์มากและเป็นบุคคลที่มีบทบาทสำคัญในการสร้างหลักการ SOLID ที่รู้จักกันดี (ใครๆ ก็เรียกว่าผู้สร้าง) นอกจากนี้ ฉันอยากจะเสริมว่าหนังสือเล่มนี้ได้รับการแนะนำโดยหัวหน้าทีมของฉันซึ่งมีประสบการณ์การทำงานมากกว่า 15 ปี
เกี่ยวกับหนังสือ
การพึ่งพา
ก่อนที่จะอ่านหนังสือ ฉันอ่านบทความเกี่ยวกับฮาเบรซึ่งมีคำว่า "การเสพติด" ปรากฏอยู่ค่อนข้างมาก มันคืออะไร ใครขึ้นอยู่กับใคร “ขึ้นอยู่กับ” หมายถึงอะไร และชั้นเรียนสามารถพึ่งพาใครบางคนได้อย่างไร?
และเมื่อฉันอ่านหนังสือ ฉันได้เรียนรู้สองสิ่ง:
การพึ่งพาเป็นคำที่หมายความว่าคลาสบางคลาส (ส่วนประกอบ บริการ) รู้เกี่ยวกับคลาสอื่น ๆ (ส่วนประกอบ บริการ) และความรู้นี้ในระดับโค้ดจะถูกกำหนด (ตอนนี้ Javaists, Sharpists, Sishniks จะเข้าใจฉัน) โดยการนำเข้าเนมสเปซบางตัว . กล่าวอีกนัยหนึ่ง: คุณมีคลาส A พร้อมด้วยเนมสเปซ Default.Classes และคลาส B Another.Classes ดังนั้นหากซอร์สโค้ดของคลาส A มีการใช้งาน Another.Classes; - นี่หมายความว่าคลาส A ขึ้นอยู่กับคลาส B
เพื่อให้เข้าใจจากแผนภาพว่าคลาสที่ต้องพึ่งพาอยู่ที่ไหนและอยู่ที่ไหน ให้ดูที่ทิศทางของลูกศร: ใน 1) ลูกศรจะชี้จากคลาส A ไปในทิศทางของคลาส B ซึ่งหมายความว่าคลาส B มีความเป็นอิสระมากกว่า คลาส A และการเปลี่ยนแปลงในคลาส A จะไม่เกิด "ความเสียหาย" กับคลาส B
มูลฝอย
เหตุผลหลักประการหนึ่งที่ทำให้ฉันอ่านหนังสือเล่มนี้คือคำอธิบายหลักการ SOLID จากต้นฉบับ เนื่องจากลุงร็อบได้พัฒนาหลักการเหล่านี้ และใครๆ ก็สามารถพูดได้ว่าต้องขอบคุณเขาที่เราได้ยินชื่อนี้ - SOLID
สำหรับผู้ที่ไม่มีความรู้ หลักการเหล่านี้พูดและแนะนำให้คุณออกแบบแอปพลิเคชันของคุณตามกฎ 5 ข้อ:
S - SRP (หลักการรับผิดชอบเดี่ยว)
O - OCP (หลักการเปิด-ปิด)
L - LSP (หลักการทดแทน Liskov)
I - ISP (หลักการแยกส่วนต่อประสาน)
D - DIP (หลักการผกผันการพึ่งพา)
หลักการทั้งหมดนี้สามารถนำไปใช้ในระดับคลาสและออบเจ็กต์ ในระดับโมดูลและส่วนประกอบ และในระดับราง (บริการ)
หากคุณคิดว่าหลักการความรับผิดชอบเดี่ยวหมายความว่าคลาสหรือโมดูลควรทำสิ่งเดียวเท่านั้น คุณจะต้องอ่านบทเกี่ยวกับ Solid อย่างน้อยที่สุด สำหรับคำจำกัดความที่ให้ไว้ข้างต้นเป็นผลที่ตามมา แต่ไม่ใช่คำจำกัดความของหลักการนั้นเอง
เกี่ยวกับการผกผันการพึ่งพา
ฉันต้องการที่จะให้ความสนใจเป็นพิเศษกับคำอธิบายของหลักการผกผันการพึ่งพา (หนึ่ง D จาก SOLID) ขณะที่ฉันอ่านหนังสือ ฉันตระหนักว่านี่ไม่ใช่แค่หลักการเท่านั้น แต่ยังเป็นกลไกและเครื่องมือที่คุณสามารถเปลี่ยนทิศทางของการพึ่งพาของคุณ และสร้าง ตัวอย่างเช่น ตรรกะทางธุรกิจ (DOMAIN) โดยไม่ขึ้นกับรายละเอียดของ การใช้ชั้นการเข้าถึงข้อมูล (DAL)
แม้ว่าหลักการนั้นเองพร้อมกับหลักการอื่นๆ ใน SOLID จะมีความหมายแตกต่างจากกลไกเล็กน้อย แต่กลไกนั้นก็ถูกใช้ตลอดทั้งเล่ม และนี่คือหนึ่งในวิธีการหลักในการกลับด้านและเปลี่ยนทิศทางของการขึ้นต่อกันของคุณ ซึ่ง โดยวิธีการใช้ใน DDD
เกี่ยวกับการตัดสินใจทางสถาปัตยกรรม
บ่อยครั้งที่หนังสือเล่มนี้จะกล่าวถึงหลักการตัดสินใจทางสถาปัตยกรรมที่สำคัญ เช่น ฐานข้อมูลใดที่จะใช้ กรอบงานใดที่จะใช้ ไลบรารีใดที่จะรวมไว้ สิ่งที่จะใช้เป็นเครื่องมือค้นหา ฯลฯ
ดังนั้นผู้เขียนเชื่อว่า: คุณควรตัดสินใจให้น้อยที่สุด เนื่องจากข้อกำหนดสามารถเปลี่ยนแปลงได้ ข้อจำกัดด้านประสิทธิภาพด้วย องค์ประกอบด้านพฤติกรรมจึงมีแนวโน้มที่จะเปลี่ยนแปลง ในระหว่างกระบวนการพัฒนา โซลูชันหนึ่งอาจดูมีประสิทธิภาพน้อยกว่าโซลูชันอื่น สะดวกน้อยกว่าโซลูชันอื่น และความแข็งแกร่งของสถาปัตยกรรมของคุณจะเป็นตัวกำหนดว่าคุณสามารถแทนที่เทคโนโลยีหนึ่งด้วยเทคโนโลยีอื่นได้อย่างรวดเร็วและไม่ลำบากเพียงใด (OCP พูดถึงเรื่องนี้)
ตัวอย่างเช่น จู่ๆ คุณตัดสินใจใช้ MongoDb แทน Postgresql หรือไฟล์โดยทั่วไป หรือใช้ข้อมูลจำลอง ซึ่งการดำเนินการจะดำเนินการในหน่วยความจำ และภายใต้เงื่อนไขบางประการ นี่สามารถบังคับให้คุณเขียนตรรกะเกือบทั้งหมดใหม่ได้
เพื่อป้องกันไม่ให้สถานการณ์ดังกล่าวเกิดขึ้น เราสามารถใช้กลไกบางอย่างที่จะชะลอเวลาการตัดสินใจให้มากที่สุด หนึ่งในกลไกเหล่านี้คือนามธรรม
ลิงค์ไปยัง DDD
DDD - การออกแบบที่ขับเคลื่อนด้วยโดเมน - แนวทางในการพัฒนาบริการด้วยตรรกะทางธุรกิจที่ซับซ้อน ซึ่งมีความสำคัญต่อการเปลี่ยนแปลง ซึ่งมีจุดมุ่งหมายเพื่อเพิ่มความเข้าใจในตำแหน่งการจัดการโครงการให้สูงสุด (PMs ผู้จัดการฝ่ายขาย ฯลฯ) กับนักพายธรรมดา นั่นคือเพื่อให้มีภาษาที่แพร่หลายระหว่างสมาชิกทุกคนของโครงการ และทุกคนสามารถเข้าใจกันและกัน และเพื่อให้ทุกคนคิดในโดเมนเดียวกันโดยมีกฎเกณฑ์ทางธุรกิจเดียวกัน
หากคุณเป็นสาวก DDD หรืออยากเป็นคนหนึ่ง หรือไม่เข้าใจอะไรสักอย่างแต่อยากเข้าใจ หนังสือเล่มนี้คือสิ่งที่ต้องอ่าน โดยเฉพาะส่วนที่สองของหนังสือ
ในที่นี้ ผู้เขียนอธิบายถึงการมีอยู่ของกฎการพึ่งพา (Dependency Rule) และเหตุผลว่าทำไมการปฏิบัติตามกฎนี้จะช่วยให้คุณสร้างสถาปัตยกรรมแอปพลิเคชันที่ถูกต้อง เหตุใดการพึ่งพาจึงควรไหลไปยังส่วนประกอบที่มีนโยบายสูง (High Policy Components) และเหตุผลอื่นๆ โดเมน (ส่วนประกอบนโยบายระดับสูง) ควรเป็นอิสระจากโครงสร้างพื้นฐาน และจะช่วยลดความซับซ้อนในการติดตั้งและพัฒนาของคุณได้อย่างไร
นามธรรม
ลุงร็อบยังพูดถึงว่ารายละเอียดการใช้งานสามารถเป็นอันตรายต่อระบบของคุณและป้องกันไม่ให้พัฒนาโดยไม่เจ็บปวดในอนาคตได้อย่างไร
จำไว้!
ฐานข้อมูลเป็นรายละเอียดการดำเนินการ
ลูกค้า (เว็บ มือถือ ฯลฯ) - รายละเอียดการใช้งาน
กรอบงานเป็นรายละเอียดการดำเนินการ
คุณต้องนามธรรมให้มากที่สุดเท่าที่จะเป็นไปได้จากทั้งหมดนี้และไม่ต้องขึ้นอยู่กับมัน โดยใช้การผกผันการพึ่งพาที่อธิบายไว้ข้างต้นพร้อมอินเทอร์เฟซและนามธรรม กฎการพึ่งพา และกลไกอื่น ๆ
วิธีการสร้างโมดูล
ฉันชอบส่วนนี้เป็นพิเศษในฐานะผู้พัฒนาบริการบน ASP .NET CORE เพราะที่นี่เราพูดถึงวิธีการสร้างสถาปัตยกรรมบริการแบบครบวงจรจากส่วนประกอบสำเร็จรูป
Robert อธิบายแผนการแยกชั้นที่เป็นไปได้ 4 แบบ
เขาชี้แจงให้ชัดเจนว่าเหตุใดกลไกที่ใช้บ่อยของสถาปัตยกรรม 3 เลเยอร์: UI (ตัวควบคุม), บริการ (โดเมน), DAL (ฐานข้อมูล) จึงค่อนข้างแย่เมื่อเทียบกับกลไกอื่น ๆ ฉันไม่ได้เห็นโปรเจ็กต์มากนัก แต่แต่ละโปรเจ็กต์ เช่น บริการไมโครที่แบ็คเอนด์ ใช้สถาปัตยกรรมสามชั้น
นอกจากนี้ บ่อยครั้งที่มีการใช้สถาปัตยกรรมแบบหนึ่งองค์ประกอบหนึ่งบริการ โดยทั่วไปแล้วทั้งคู่ค่อนข้างดี แต่ก็มีข้อเสียค่อนข้างมากเมื่อเปรียบเทียบกับวิธีการสร้างสถาปัตยกรรมเมื่อใช้ DDD โดยเฉพาะอย่างยิ่งกับบริการที่สำคัญและบริการที่ซับซ้อน
อย่างไรก็ตาม นี่เป็นจุดสิ้นสุดของการรีวิวหนังสือเล่มนี้ ฉันชอบหนังสือเล่มนี้มาก ฉันไม่เสียใจที่ได้อ่านมัน ขอบคุณผู้เขียน สำหรับคุณผู้อ่านที่รักขอขอบคุณสำหรับความสนใจอย่าตัดสินอย่างเคร่งครัด - สิ่งพิมพ์นี้อิงจากความประทับใจในหนังสือและความกระตือรือร้นส่วนตัวของฉัน
ที่มา: will.com
