5 คะแนน โดย GN⁺ 2025-03-29 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • หนังสือที่ Harry ผู้เขียน "TDD with Python" และ Bob สถาปนิกซอฟต์แวร์ ร่วมกันอธิบายวิธีทำความเข้าใจและจัดการสถาปัตยกรรมซอฟต์แวร์ที่ซับซ้อน
  • รวบรวมและแบ่งปันเทคนิคด้านสถาปัตยกรรมที่ใช้งานจริงในบริษัทอีคอมเมิร์ซ
  • MADE.com เป็นบริษัทขายเฟอร์นิเจอร์ออนไลน์ในยุโรปที่ดำเนินงานซัพพลายเชนระดับโลก
    • เป้าหมายคือปรับโลจิสติกส์ให้เหมาะสมเพื่อลดสต็อกให้เหลือน้อยที่สุด และประสานให้สินค้าด้านโลจิสติกส์มาถึงพร้อมกับคำสั่งซื้อของลูกค้า
  • แต่โลกความเป็นจริงมีความซับซ้อนและคาดเดาไม่ได้ จึงมีการสร้างซอฟต์แวร์อัจฉริยะที่สะท้อนเงื่อนไขเหล่านี้เพื่อทำงานอัตโนมัติ
  • หนังสือเล่มนี้กล่าวถึงแพตเทิร์นสถาปัตยกรรมที่ออกแบบมาเพื่อแก้ปัญหาเชิงปฏิบัติเหล่านั้น

ทำไมต้อง Python

  • Python เป็นภาษาที่เติบโตอย่างรวดเร็วทั่วโลก และกำลังเผชิญกับปัญหาองค์กรที่ซับซ้อนมากขึ้นเรื่อย ๆ
  • หนังสือด้านสถาปัตยกรรมที่มีอยู่เดิมส่วนใหญ่ใช้ตัวอย่างบน Java หรือ C# ทำให้ผู้ใช้ Python เข้าถึงได้ยาก
  • หนังสือเล่มนี้นำเสนอแพตเทิร์นสถาปัตยกรรมแบบคลาสสิกในรูปแบบที่เหมาะกับชุมชน Python

แนะนำ TDD, DDD และสถาปัตยกรรมแบบ event-driven

  • TDD (Test-Driven Development):
    • การพัฒนาโดยให้การทดสอบมาก่อน ช่วยให้รีแฟกเตอร์และเพิ่มฟีเจอร์ได้อย่างมั่นคง
    • ควรให้ความสำคัญกับ unit test ที่รวดเร็วและไม่มี dependency ก่อน และลด end-to-end test ที่ช้าและไม่เสถียรให้น้อยที่สุด
  • DDD (Domain-Driven Design):
    • แม้จะเน้นที่โมเดลโดเมนทางธุรกิจ แต่การลดการพึ่งพาโครงสร้างพื้นฐานและเฟรมเวิร์กก็เป็นสิ่งสำคัญ
  • สถาปัตยกรรมแบบ event-driven:
    • จัดการความซับซ้อนด้วยการสื่อสารแบบใช้ข้อความระหว่างไมโครเซอร์วิส
    • จำเป็นต้องพิจารณาว่าจะผสานเข้ากับเครื่องมือ Python ที่มีอยู่ เช่น Flask, Django, Celery ได้อย่างไร

หมายเหตุ: แพตเทิร์นส่วนใหญ่ที่กล่าวถึงในหนังสือเล่มนี้สามารถนำไปใช้กับสถาปัตยกรรมแบบ monolithic ได้เช่นกัน

  • จุดมุ่งหมายของหนังสือเล่มนี้คือการแนะนำแพตเทิร์นสถาปัตยกรรมที่รองรับ TDD, DDD และบริการแบบ event-driven ใน Python พร้อมแนวทางการนำไปใช้

ผู้อ่านเป้าหมายของหนังสือเล่มนี้

  • นักพัฒนาที่มีประสบการณ์ในการจัดการแอปพลิเคชัน Python ที่ซับซ้อน
  • ไม่จำเป็นต้องมีความรู้พื้นฐานเกี่ยวกับแพตเทิร์นสถาปัตยกรรมหรือ DDD มาก่อน
  • ออกแบบให้สามารถติดตามได้แม้จะยังไม่คุ้นเคยกับสไตล์ TDD ที่เขียนการทดสอบก่อนแล้วจึงลงมือพัฒนา
  • มีการใช้ Flask, SQLAlchemy, pytest, Docker, Redis ฯลฯ แต่ไม่ใช่ความรู้บังคับ
  • เป้าหมายคือการออกแบบสถาปัตยกรรมที่ไม่ผูกติดกับเทคโนโลยีเฉพาะ

ภาพรวมสิ่งที่จะได้เรียนรู้

Part 1

  • การทำ domain modeling และ DDD (บทที่ 1, 2, 7)
    • แนะนำวิธีสร้างโมเดลโดเมนโดยไม่พึ่งพา dependency ภายนอก
    • วิธีเขียน unit test ที่รวดเร็ว และการพิจารณาความสัมพันธ์กับความสมบูรณ์ของข้อมูล
    • อธิบายวิธีเลือก Aggregate ที่เหมาะสม
  • แพตเทิร์น Repository, Service Layer, Unit of Work (บทที่ 2, 4, 5)
    • แยกโมเดลออกจาก dependency ภายนอกด้วยการทำ abstraction ของ persistence layer
    • ออกแบบ service layer ให้เป็นจุดเข้าสู่ระบบ
    • เหมาะสำหรับการสร้างจุดเข้าระบบแบบบาง เช่น Flask API หรือ CLI
  • ข้อคิดเกี่ยวกับการทดสอบและ abstraction (บทที่ 3, 5)
    • สำรวจเกณฑ์และบทบาทของการเลือกระดับ abstraction ที่เหมาะสม
    • เขียน unit test ในระดับ abstraction ที่สูงขึ้นเพื่อให้ได้ test pyramid

Part 2

  • สถาปัตยกรรมแบบ event-driven (บทที่ 8–11)
    • แนะนำแพตเทิร์น Domain Events, Message Bus และ Handler
    • ใช้ event เพื่อกระตุ้นปฏิสัมพันธ์ภายในระบบ
    • อธิบายวิธีผสานการทำงานระหว่างไมโครเซอร์วิสด้วย event
    • แยกความแตกต่างระหว่าง command และ event
    • เปลี่ยนทั้งแอปพลิเคชันให้กลายเป็นระบบประมวลผลข้อความ
  • CQRS (Command-Query Responsibility Segregation) (บทที่ 12)
    • แนะนำประสิทธิภาพเชิงโครงสร้างจากการแยกความรับผิดชอบระหว่าง command และ query
    • มีตัวอย่างการใช้งานทั้งกรณีที่ใช้ event และไม่ใช้ event
  • การฉีด dependency (บทที่ 13)
    • จัดระเบียบ dependency แบบ explicit/implicit
    • ลงมือสร้างเฟรมเวิร์กสำหรับการฉีด dependency แบบเรียบง่าย

ภาคผนวกและคู่มือภาคปฏิบัติ

  • วิธีนำไปใช้กับโปรเจ็กต์เดิม (Epilogue)
    • การนำแพตเทิร์นไปใช้กับระบบเดิมยากกว่าการทำตัวอย่างง่าย ๆ
    • มีการให้กลยุทธ์การประยุกต์ใช้และแหล่งอ้างอิงสำหรับเรื่องนี้
  • แบบฝึกโค้ดและตัวอย่างบน GitHub
    • เนื้อหาทั้งหมดของหนังสือถูกรวมเป็นโปรเจ็กต์ตัวอย่างเดียว
    • ในแต่ละบทมีโค้ดให้ผ่าน GitHub branch
    • รูปแบบการฝึกปฏิบัติ:
      • ลงมือสร้างแอปตัวอย่างตามด้วยตนเอง
      • ทดลองนำแพตเทิร์นไปใช้กับโปรเจ็กต์ของตนเอง
      • ใช้ "Exercise for the Reader" ของแต่ละบทเพื่อฝึกเขียนโค้ด

เคล็ดลับ: แนะนำให้ checkout branch ที่เกี่ยวข้องบน GitHub ตั้งแต่ต้นบท เพื่อเรียนรู้ไปพร้อมกับโค้ดที่ทำงานได้จริง

2 ความคิดเห็น

 
xguru 2025-03-29

มีฉบับแปลภาษาเกาหลีออกมาแล้ว Architecture Patterns with Python

 
GN⁺ 2025-03-29
ความคิดเห็นจาก Hacker News
  • หนังสือเล่มนี้เหมือนขุมทรัพย์เกี่ยวกับ architectural patterns ชอบตรงที่ทำให้เข้าใจหัวข้อได้ง่าย

    • แต่ในทางปฏิบัติ patterns แบบนี้อาจก่อให้เกิดปัญหาด้านความซับซ้อนและประสิทธิภาพได้ โดยเฉพาะเมื่อใช้เฟรมเวิร์กที่มีแนวทางชัดเจนอยู่แล้วอย่าง Django
    • เคยมีประสบการณ์ใช้ Python ทั้งในบริษัทใหญ่และบริษัทเล็ก บริษัทใหญ่ที่ใช้ architectural patterns แบบเคร่งครัดนั้นโค้ด "สะอาด" แต่ซับซ้อนเกินไปและช้า
    • ในทางกลับกัน บริษัทใหญ่ที่มองข้าม patterns กลับมีโค้ดที่รกมาก แต่ทำงานได้มีประสิทธิผลสูง แม้โค้ดจะรกก็ยังอ่าน เข้าใจ และแก้ไขได้
    • นี่อาจเป็นเรื่องเฉพาะตัวของผมเอง แต่ผมทำงานได้มีประสิทธิผลมากกว่าในบริษัทที่โค้ดไม่เป็นแบบแผน เพราะไม่ต้องหลบการถกเถียงเรื่อง clean code
  • บางส่วนของหนังสือเล่มนี้มีประโยชน์มาก โดยเฉพาะตอนที่พูดถึงแนวคิดซึ่งไม่ได้จำกัดอยู่แค่ Python หรือภาษาใดภาษาหนึ่ง

    • แต่บางส่วนก็มีปัญหา และอาจเป็นอันตรายได้เมื่อนักพัฒนาที่ประสบการณ์ยังน้อยพยายามนำทุกอย่างไปใช้พร้อมกัน
    • ตัวอย่างเช่น repository pattern โดยทั่วไปมีประโยชน์ แต่ในหลายกรณีรวมถึงตัวอย่างในหนังสือ มันแค่เพิ่มความซับซ้อน
    • service layer และ unit of work มีประโยชน์กับแอปพลิเคชันที่ซับซ้อน แต่ในระบบที่ประกอบด้วยบริการขนาดเล็กอาจกลายเป็นสิ่งที่ใหญ่เกินความจำเป็น
    • design patterns ก็เหมือนเครื่องมืออื่น ๆ คือควรเข้าใจว่าเมื่อไรควรใช้และเมื่อไรไม่ควรใช้ หนังสือเล่มนี้ให้คำแนะนำเรื่องนี้อยู่ แต่ควรเน้นให้มากกว่านี้
  • มองว่า Python เป็นภาษา glue language ที่ดี

    • เป็นการตอบโต้ต่อแนวคิด OOP ที่ถูกยัดเยียด การบังคับให้ทุกอย่างต้องมี encapsulation และ inheritance
    • เป็นการตอบโต้ต่อ SOLID, clean coding, clean architecture, GoF patterns, Uncle Bob
    • ใช้แนวทางแบบ imperative หรือ functional flow และใช้ OOP ให้น้อยที่สุดเท่าที่จะทำได้
    • เวลาใช้ Python อยากได้ประสบการณ์ที่ไม่มีวัตถุและไม่มี patterns
    • ไม่ได้แปลว่าหนังสือเล่มนี้ไม่มีคุณค่า มันมีประโยชน์ในการเรียนรู้ patterns แต่ไม่ควรพยายามยัดทุกอย่างให้เข้ากับการเขียนโปรแกรมจริง
  • ผมเป็นนักพัฒนา TypeScript แต่หนังสือเล่มนี้เป็นหนึ่งในหนังสือด้าน architecture ที่ผมชอบที่สุด และอ้างอิงอยู่เสมอ

    • ผมใช้ fake unit of work/service pattern สำหรับการทดสอบแบบเคร่งครัดมาก มันช่วยในการทำ third-party services ให้เป็นของปลอมได้
    • แนะนำให้ตั้งชื่อ events ในแบบที่เฉพาะกับโดเมน ซึ่งช่วยแก้ปัญหาส่วนที่ต้องอธิบายให้เพื่อนร่วมทีมฟังแล้วมักยุ่งยาก
    • Cosmic Python เปิดให้อ่านออนไลน์ทั้งหมด จึงลิงก์ต่อได้ง่าย โดยรวมแล้วเป็นทรัพยากรที่ยอดเยี่ยมและมีอิทธิพลต่อแนวคิดมาก
  • เริ่มเขียน Python แบบมืออาชีพตั้งแต่หลายปีก่อน มาจาก Kotlin และ TypeScript แม้ภาษาจะเข้าถึงง่าย แต่ก็ลำบากในการทำให้เกิด loose coupling และ testability

    • ตามคำแนะนำของเพื่อนร่วมงานจึงซื้อหนังสือเล่มนี้และอ่านตั้งแต่ต้นจนจบ มันช่วยให้เข้าใจวิธีจัดการความซับซ้อนใน codebase Python ที่ซับซ้อน
    • ไม่ได้ทำตามทุก pattern แต่ทำให้รู้ถึงความเป็นไปได้และวิธีนำประสบการณ์จาก paradigms อื่นมาใช้กับ Python
    • แนะนำอย่างยิ่ง คุ้มค่าแน่นอน
  • เป็นหนึ่งในหนังสือการเขียนโปรแกรม Python ที่ยอดเยี่ยมจริง ๆ เสียดายที่โค้ดไม่มี static typing แต่ก็เป็นการตัดสินใจโดยตั้งใจของผู้เขียน

  • ขอบคุณที่แชร์แหล่งข้อมูลดี ๆ

  • ผมอ่านฉบับปกอ่อนของหนังสือเล่มนี้เมื่อ 2 ปีครึ่งหรือ 3 ปีก่อน สนุกมาก มันทำให้การทดสอบยังคงเป็นหัวข้อระดับ first-class และคอยอัปเดตอย่างต่อเนื่องทุกครั้งที่มีการเพิ่มอะไรเข้าไป

    • การที่การทดสอบพร้อมใช้งาน เขียนง่าย และอัปเดตง่าย ทำให้กระบวนการพัฒนาสนุกขึ้น และลดความจำเป็นที่จะต้องรันโค้ดด้วยมือเพื่อดูปัญหา
    • ส่วนของ event-oriented น่าสนใจ แต่ในงานปัจจุบันยังไม่ค่อยใช้งานได้จริงพอจะนำไปใช้
  • ไม่มีการพูดถึง Polylith เลย สงสัยว่ามันเกี่ยวข้องกันไหม

  • หนังสือเล่มนี้อ่านสนุกมาก เมื่อ 3 ปีก่อนผมทำงานในสภาพแวดล้อม C#/.NET DDD และตอนนี้กลับมาทบทวนแนวคิดเหล่านี้อีกครั้งใน Python พร้อมกับขัดเกลาส่วนที่เป็นแก่นสำคัญ

    • ถ้าสนใจหัวข้อแบบนี้ แนะนำอย่างยิ่ง