Summary (สรุป)

ในบทนี้ คุณได้เรียนรู้เล็กน้อยเกี่ยวกับสิ่งที่ทำให้ขอบเขตของ microservice ดี และวิธีหาแนวรอยต่อ (seams) ในพื้นที่ปัญหาของเราที่ให้ประโยชน์สองต่อ ทั้ง coupling ที่ต่ำและ cohesion ที่แข็งแรง การมีความเข้าใจอย่างละเอียดเกี่ยวกับ domain ของเราสามารถเป็นเครื่องมือสำคัญที่ช่วยให้เราหาแนวรอยต่อเหล่านี้ได้ และการจัด microservices ของเราให้สอดคล้องกับขอบเขตเหล่านี้ทำให้เรามั่นใจได้ว่าระบบที่ได้จะมีโอกาสรักษาคุณสมบัติเหล่านั้นไว้ได้ เรายังได้เห็นแนวทางบางอย่างเกี่ยวกับวิธีที่เราสามารถแบ่งย่อย microservices ของเราต่อไปได้อีกด้วย

แนวคิดที่นำเสนอในหนังสือ Domain-Driven Design ของ Eric Evans มีประโยชน์อย่างมากกับเราในการหาขอบเขตที่สมเหตุสมผลสำหรับ service ของเรา และผมเพิ่งจะแตะผิวเผินเท่านั้นตรงนี้ หนังสือของ Eric ลงรายละเอียดมากกว่านี้มาก ถ้าคุณอยากเจาะลึกมากขึ้น ผมขอแนะนำหนังสือของ Vaughn Vernon เรื่อง Implementing Domain-Driven Design 17 เพื่อช่วยให้คุณเข้าใจแง่มุมเชิงปฏิบัติของแนวทางนี้ ในขณะที่ Domain-Driven Design Distilled 18 ของ Vernon ก็เป็นภาพรวมแบบย่อที่ยอดเยี่ยมถ้าคุณกำลังมองหาอะไรที่กระชับกว่า

บทนี้ส่วนใหญ่ได้อธิบายว่าเราจะหาขอบเขตสำหรับ microservices ของเราได้อย่างไร แต่จะเกิดอะไรขึ้นถ้าคุณมีแอปพลิเคชันแบบ monolithic อยู่แล้วและกำลังมองหาทางย้ายไปสู่สถาปัตยกรรม microservice นั่นคือสิ่งที่เราจะสำรวจกันต่อไปในรายละเอียดมากขึ้นในบทถัดไป

1 David, Parnas, "On the Criteria to Be Used in Decomposing Systems into Modules," (journal contribution, Carnegie Mellon University, 1971), https://oreil.ly/BnVVg .

2 จุดเริ่มต้นที่ชัดเจนคือบทสรุปของ Adrian เรื่อง "On the Criteria…" แต่การนำเสนอผลงานก่อนหน้าของ Parnas โดย Adrian เรื่อง "Information Distribution Aspects of Design Methodology" มีข้อมูลเชิงลึกที่ดีมากพร้อมคำอธิบายจาก Parnas เอง

3 Parnas, "Information Distribution Aspects."

4 น่ารำคาญที่ผมหาแหล่งที่มาดั้งเดิมของคำจำกัดความนี้ไม่เจอ

5 ในหนังสือของผมเรื่อง Monolith to Microservices (O'Reilly) ผมให้เครดิตประโยคนี้กับ Larry Constantine เอง แม้ว่าประโยคนี้จะสรุปงานของ Constantine ในด้านนี้ได้อย่างกระชับ แต่จริง ๆ แล้วคำพูดนี้ควรให้เครดิตกับ Albert Endres และ Dieter Rombach จากหนังสือของพวกเขาปี 2003 เรื่อง A Handbook of Software and Systems Engineering (Addison-Wesley)

6 Edward Yourdon and Larry L. Constantine, Structured Design (New York: Yourdon Press, 1976).

7 Meilir Page-Jones, The Practical Guide to Structured Systems Design (New York: Yourdon Press Computing, 1980).

8 แนวคิดนี้คล้ายกับ domain application protocol ซึ่งกำหนดกฎที่ component ต่าง ๆ ใช้โต้ตอบกันในระบบแบบ REST-based

9 Pass-through coupling เป็นชื่อที่ผมตั้งขึ้นเองสำหรับสิ่งที่เดิมทีถูกเรียกว่า "tramp coupling" โดย Meilir Page-Jones ใน The Practical Guide to Structured Systems Design ผมเลือกใช้คำที่ต่างออกไปตรงนี้เพราะผมพบว่าคำเดิมมีปัญหาอยู่บ้างและไม่ค่อยมีความหมายชัดเจนสำหรับผู้อ่านในวงกว้าง

10 ใช่ครับ มากกว่าหนึ่งหรือสองครั้ง มากกว่านั้น มาก เลยด้วยซ้ำ...

11 Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (Boston: Addison-Wesley, 2004).

12 ผมรู้ว่าบางคนคัดค้านการใช้ templated URI ในระบบ REST และผมก็เข้าใจว่าทำไม ผมแค่อยากทำให้เรื่องเรียบง่ายสำหรับตัวอย่างนี้

13 Phil Calçado, "Pattern: Using Pseudo-URIs with Microservices," https://oreil.ly/xOYMr .

14 ผมไม่ได้มีเจตนาไม่ให้เกียรติถ้านี่คือคุณ ผมเองก็เคยทำแบบนี้มากกว่าหนึ่งครั้งเช่นกัน

15 คือ ทำไมไม่ใช้สีเหลืองล่ะ มันเป็นสีที่หาง่ายที่สุด!

16 Alberto Brandolini, EventStorming (Victoria, BC: Leanpub, forthcoming).

17 Vaughn Vernon, Implementing Domain-Driven Design (Upper Saddle River, NJ: Addison-Wesley, 2013).

18 Vaughn Vernon, Domain-Driven Design Distilled (Boston: Addison-Wesley, 2016).