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

微服務是從認知負載角度劃分的，每個團隊都是由人組成的，人都是認知能力限制或天花板的，這些決定了團隊的認知能力大小，一個團隊不可能建立或管理其認知能力之外的領域上下文知識，也就無法建立和管理相應的微服務，認知負載邊界=微服務邊界。

根據康威定理，組織架構決定了技術架構，那麼就要逆康威定律，如果你想要一個微服務架構，那麼就改造你的團隊結構，這就是團隊拓撲的由來，團隊拓撲由四個團隊組成：業務流對齊團隊，這與有界上下文（限界上下文）對應對齊的，其他三個都是支援性團隊，其中平臺團隊類似DevOps團隊，其他支援性團隊在時間上不是永久捆綁在上下文裡，而是對所有流對齊團隊提供支援。

那麼平臺團隊比較特殊：

事實上，我們建立了一個平臺團隊，因為其目的是減少團隊在特定部分的認知負擔。

但是，根據最近的學習，我們認為它本身可能是一個有界上下文，至少是一個支援子域。

這是對同一問題空間使用不同視角幫助您找到最佳團隊組成的情況之一。

幫助我們識別這種情況的原因是使用 Big Picture Event Storming（戰略圖事件風暴） 來促進對部落（特殊的團隊）識別新業務能力的快速學習：關於我們正在研究的領域的缺失知識，並且是重要的知識。

有趣的是，起初，它似乎是為了減少認知負荷，後來演變成一種支援性的業務能力，將平臺作為一種產品和支援性的上下文來共享。

也就是說：流對齊團隊通過平臺工程這樣的運維工程共享平臺團隊的能力，不再需要人工現場配合工作了。

像往常一樣，讓企業參與進來，一起做一些探索，可以幫助你在做決定的時候更早地瞭解。

然而，我們瞭解了商業業務領域，我們也更好地理解了這種情況。

識別有界上下文（BC：有邊界的環境）仍然是一個關鍵挑戰。