Teams, Cognitive Load and Ownership#

Context Map ที่สวยแต่ capability หนึ่งต้องผ่าน Frontend, Backend, Database และ Integration teams 4 handoffs ยังส่งมอบช้า ในทางกลับกันการย้าย org chart ให้ทีมละ 1 Bounded Context โดยไม่ดูทักษะ, cognitive load และคนจริงอาจสร้าง silo ใหม่ DDD กับ Team Topologies เสริมกันแต่ไม่ใช่สูตรเดียวกัน

2 Lenses ที่ต้องใช้ร่วมกัน#

• DDD: model/language/decision boundary และ relationship
• Team Topologies: flow of change, cognitive load, team types และ interaction modes

Team Topologies Key Concepts เสนอ Stream-aligned, Platform, Enabling, Complicated Subsystem teams และ Collaboration, X-as-a-Service, Facilitation แต่ไม่ได้บอกว่าแต่ละ Bounded Context ต้องเท่ากับทีมเสมอ

Ownership มีหลายมิติ#

การเขียนชื่อ team บนกล่องเดียวไม่พอ หากคนละ ownership ต้องมี decision rights และ escalation

Cognitive Load เป็น Boundary Signal#

ถามทีมว่าเข้าใจ/ดูแลได้หรือไม่:

• domain concepts/policies จำนวนเท่าใด
• integrations และ failure modes กี่แบบ
• operational platform work กลบ domain work หรือไม่
• context switching ระหว่าง unrelated capabilities สูงหรือไม่
• specialist knowledge ควรเป็น service/platform หรืออยู่ในทีม

Boundary ที่ semantically สวยแต่เกิน cognitive capacity ไม่ยั่งยืน อาจ split responsibility, ลด platform burden หรือใช้ enabling team ก่อน split model

Team– Context Shapes#

1 ทีมต่อหลาย Contexts#

ปกติใน small business ให้รักษา code/language boundaries แม้คนชุดเดียว ใช้ explicit hats/owners และอย่าสร้าง network services เพื่อเลียนแบบ org ใหญ่

หลายทีมต่อ 1 Context#

เกิดใน context ใหญ่ ต้องมี sub-boundaries, common language governance และ clear decision owner ถ้าทีมแบ่งตาม technical layer change จะ handoff สูง พิจารณา stream slices โดยไม่ split context เพียงเพื่อให้ลง org chart

1 ทีมต่อ 1 Context#

เหมาะเมื่อ scope อยู่ใน cognitive load และ team build/run end-to-end แต่ยังต้องมี relationships กับ contexts อื่น ไม่ใช่ autonomy แบบไม่รับผิดชอบ consumers

System map

ทั้ง 3 รูปแบบเกิดขึ้นได้ Diagram ไม่ใช่ maturity ladder สิ่งที่ต้องชัดเสมอคือ decision owner, language governance, contract responsibility และ cognitive load ที่แต่ละทีมรับไหว

Interaction Mode ตามเวลา#

• Collaboration: discovery หรือ redesign ที่ uncertainty สูง; bandwidth สูงและควร timebox
• X-as-a-Service: contract stable; consumer self-service และ support expectation ชัด
• Facilitation: enabling team ช่วย modelling/testing skill ชั่วคราวแล้วถอนตัว

หาก collaboration ถาวร อาจมี boundary/contract ที่ยังไม่ resolve หาก X-as-a-Service ต้องประชุมทุกครั้ง API/platform ยังไม่ใช่ service experience ที่ดี

Flow Evidence#

ใช้ metrics เป็น diagnosis ไม่เป็น leaderboard:

• wait/handoff time
• teams touched ต่อ change
• coordinated deployment percentage
• upstream change lead time
• incident routing time
• domain knowledge concentration
• team cognitive-load pulse

DORA Loosely Coupled Teams สนับสนุน การมอง ability to change/test/deploy independently แต่ต้องวัดต่อ context/application ไม่เปรียบเทียบ ทีมต่าง domain แบบตรง ๆ

แบบฝึกปฏิบัติ: Ownership Overlay#

นำ Context Map Transfer มา overlay:

Context:
Business / model / contract / delivery / operations / data owners:
Team cognitive-load risks:
Current interaction mode with each neighbor:
Desired mode and duration:
Handoff evidence:
Constraint that prevents simple realignment:
Next organizational experiment:

สร้าง variants สำหรับทีม 1 ทีม, 4 teams และ corporate หลายประเทศ โดยรักษา semantic boundary แต่ปรับ ownership/interaction ตาม capacity

รายการตรวจสอบ#

• DDD boundary แยกจาก team design
• ownership หลายมิติถูกตั้งชื่อ
• cognitive load และ flow เป็น evidence
• 1:1 เป็นทางเลือกไม่ใช่ invariant
• interaction mode มี purpose/duration
• platform/enabling ลด load ไม่ยึด model ownership
• control constraint มี accountable source

อ่านเพิ่มเติม#

• Team Topologies Key Concepts — team types และ interaction modes
• Finding Software Boundaries for Fast Flow
• DORA Loosely Coupled Teams — flow signals