Team Topology Considerations (ข้อพิจารณาด้าน Team Topology)

เนื่องจาก modular monolith ถูกนับเป็น domain-partitioned architecture มันจึงทำงานได้ดีที่สุดเมื่อทีมงานถูกจัดวางตามพื้นที่ domain ด้วยเช่นกัน (เช่น cross-functional team ที่มีความเชี่ยวชาญเฉพาะทาง) เมื่อมี requirement ที่อิงตาม domain เข้ามา ทีมข้ามสายงานที่เน้น domain สามารถทำงานร่วมกันในฟีเจอร์นั้นได้ ตั้งแต่ presentation logic ไปจนถึงฐานข้อมูล ในทางกลับกัน ทีมที่จัดระเบียบตามหมวดหมู่เชิงเทคนิค (เช่น ทีม UI, ทีม backend, ทีม database และอื่น ๆ) จะทำงานร่วมกับ architectural style นี้ได้ไม่ดี ส่วนใหญ่เป็นเพราะการแบ่งพาร์ทิชันตาม domain ของมัน การมอบหมาย requirement ที่อิงตาม domain ให้กับทีมที่จัดระเบียบตามเทคนิคต้องใช้การสื่อสารและความร่วมมือมาก ซึ่งมักพิสูจน์แล้วว่าทำได้ยาก

ต่อไปนี้คือข้อพิจารณาบางประการสำหรับการจัดวาง team topology เฉพาะที่ระบุไว้ใน “Team Topologies and Architecture” ให้เข้ากับ modular monolith style:

Stream-aligned teams

Stream-aligned team โดยทั่วไปจะเป็นเจ้าของ flow ผ่านระบบตั้งแต่ต้นจนจบ ซึ่งเข้ากันได้ดีกับรูปทรงแบบ monolithic และจบในตัวเองโดยทั่วไปของ modular monolith

Enabling teams

เนื่องจาก style นี้มี modularity สูงและมีการแยก concern enabling team topology ก็ทำงานได้ดีเช่นกัน ผู้เชี่ยวชาญและสมาชิกทีมที่ทำงานข้ามสายงานสามารถเสนอแนะและทดลองได้โดยการเพิ่ม module เพิ่มเติมเข้าไปในระบบ โดยมีผลกระทบต่อ module อื่น ๆ ที่มีอยู่แล้วน้อยที่สุด

Complicated-subsystem teams

แต่ละ module ใน modular monolith architecture โดยทั่วไปจะทำหน้าที่เฉพาะตาม domain หรือ subdomain ของมัน (เช่น PaymentProcessing ) สิ่งนี้เข้ากันได้ดีกับ complicated-subsystem team topology เพราะสมาชิกทีมต่างคนต่างสามารถมุ่งเน้นไปที่การประมวลผล domain หรือ subdomain ที่ซับซ้อนได้อย่างเป็นอิสระจากสมาชิกทีมคนอื่น (และ module อื่น)

Platform teams

นักพัฒนาสามารถใช้ประโยชน์จาก platform-team topology ได้โดยใช้เครื่องมือ, service, API และงานที่ใช้ร่วมกัน ซึ่งส่วนใหญ่เป็นเพราะระดับ modularity ที่สูงที่พบใน architectural style นี้