DDD與團隊拓撲以及微服務之間的關係圖 - aleixmorgadas

 
事實上，我們建立了一個平臺團隊，因為其目的是減少團隊在特定部分的認知負擔。
但是，根據最近的學習，我們認為它本身可能是一個有界上下文，至少是一個支援子域。
這是對同一問題空間使用不同視角幫助您找到最佳團隊組成的情況之一。
幫助我們識別這種情況的原因是使用 Big Picture Event Storming（戰略圖事件風暴） 來促進對部落（特殊的團隊）識別新業務能力的快速學習：關於我們正在研究的領域的缺失知識，並且是重要的知識。
有趣的是，起初，平臺團隊似乎是為了減少認知負荷，後來演變成一種支援性的能力，這種能力如果涉及業務以 SaaS方式提供服務，那麼可將平臺作為一種產品和支援性的上下文來共享。
也就是說：流對齊團隊透過平臺SaaS共享平臺團隊的能力，不再需要人工現場配合工作了。
但是，如果平臺團隊是透過平臺工程這樣的運維工程提供 CI/CD或基礎設施DevOps能力，則不屬於業務。
 
banq觀點：團隊拓撲中只有流對齊團隊才涉及業務流，工作在限制的上下文BC中，其他團隊或提供業務內的除了核心子域以外的支援，或提供業務外的IT平臺性技術服務。但是，對於平臺團隊內部，可以將平臺作為產品來實現，這就屬於平臺工程，當然還有為流對齊團隊提供支援的大資料團隊，他們如果也有自己的平臺產品。所以，團隊拓撲中，如果其他支援團隊能力強，認知能力好，可以透過打造產品的形式與流對齊團隊合作，替代人工合作，無論人工還是產品API整合，都屬於上下文對映範疇需要考慮設計的。