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

แม้ space-based architecture จะถูกจัดว่าเป็น technically partitioned architecture เป็นส่วนใหญ่ เนื่องจาก มี artifact จำนวนมากที่ประกอบกันเป็น domain หรือ subdomain แต่ละอย่าง แต่มันจะมีประสิทธิภาพมากที่สุดกับ ทีมแบบ technically partitioned ที่จัดวางตาม technical area ของมัน (เช่น functionality, data pump, data reader และ data writer และการจัดการฐานข้อมูล backend) อย่างไรก็ตาม มันก็ยังสามารถทำงานได้ดีเมื่อทีมถูก จัดตาม domain area (เช่น cross-functional team ที่มีความเชี่ยวชาญเฉพาะทาง) ต่อไปนี้เป็นสิ่งที่ควร พิจารณาเกี่ยวกับการจัดวาง team topology เฉพาะที่ระบุไว้ใน “Team Topologies and Architecture” กับ space-based architecture:

Stream-aligned teams

ขึ้นอยู่กับขนาดของระบบ stream-aligned team อาจพบว่าตัวเองมีปัญหาในการ implement การเปลี่ยนแปลงที่อิง ตาม domain เนื่องจากลักษณะ technical partitioning ของ architectural style นี้ ตัวอย่างเช่น การ เปลี่ยนแปลงแบบ stream-based อาจกระทบ processing unit, data pump, data reader, data writer, cache contract หรือ orchestrator หนึ่งตัวหรือมากกว่า รวมถึง backing database ด้วย นี่อาจเป็นภาระมากสำหรับ ทีม stream-based ทีมเดียวในการจัดการ โดยเฉพาะถ้า artifact เหล่านั้นถูกใช้ร่วมกับทีมอื่น ยิ่งระบบใหญ่ และซับซ้อนมากเท่าไหร่ stream-aligned team ก็จะยิ่งมีประสิทธิภาพน้อยลงเมื่อทำงานกับ space-based architecture

Enabling teams

เนื่องจาก artifact บางส่วนของ style นี้ (data pump, data reader, data writer และ virtualized middleware) อาจถูกใช้ร่วมกันหรือเป็น cross-cutting จึงเหมาะกับ enabling team การมอบหมายทีมให้ดูแล artifact เฉพาะอย่าง (เช่น data writer และ data pump ที่เกี่ยวข้อง) จะช่วยให้สมาชิกในทีมสามารถทดลอง และหาวิธีทำให้ artifact เหล่านี้มีประสิทธิภาพมากขึ้นได้ โดยไม่ขึ้นกับทีมที่ทำงานเกี่ยวกับฟังก์ชันหลัก ใน processing unit ใดตัวหนึ่ง

Complicated-subsystem teams

complicated-subsystem team สามารถใช้ประโยชน์จากธรรมชาติแบบ technically partitioned ของ space-based architecture style เพื่อโฟกัสที่ส่วนใดส่วนหนึ่งของระบบ (เช่น data grid หรือ data pump) artifact บาง ตัวอาจซับซ้อนมาก จึงเหมาะกับ complicated-subsystem team topology การจัดการ data collision (ดู “Data Collisions” ) และข้อผิดพลาดด้าน asynchronous data synchronization ประเภทอื่น ๆ ใน data writer นั้นซับซ้อนพอ สมควร นี่เป็นตัวอย่างที่ดีของ complicated subsystem ที่ functional domain-based team ซึ่งทำงานกับ processing unit ไม่จำเป็นต้องกังวลด้วย

Platform teams

เช่นเดียวกับ architectural style ส่วนใหญ่ นักพัฒนาที่ทำงานกับ space-based architecture สามารถใช้ ประโยชน์จาก platform-team topology ได้ด้วยการใช้ tool, service, API และงานที่ใช้ร่วมกัน โดยเฉพาะถ้า ส่วนที่เกี่ยวกับ infrastructure ของ architecture (เช่น data pump และ virtualized middleware) ถูกจัด ว่าเกี่ยวข้องกับ platform