《領域驅動設計》作者Eric Evans在Explore DDD主題演講會上呼籲與會者積極參與改進用於複雜系統的建模和設計語言。Evans承認，DDD中使用的一些基本術語（例如有界上下文）經常被誤解。其他短語（如“遺留軟件”）由於個人偏見會導致在架構系統時效率低下。在提出了幾個更清晰的語言選擇之後，他希望其他人能夠發表不同的觀點。只有藉助積極的社區和富有成效的辯論，我們才能讓DDD成爲“一個真正有生命力的思想體”。
Evans認爲，在他的書出版15年之後，也就是現在，可能是時候回到最基礎的原則，並有意識地向前邁出新的一步。其中的一個關注點是澄清有界上下文、子域和組織這三個概念所導致的混淆。在很多情況下，一個有界上下文對應一個組織或團隊，也可以對應一個子域。然而，大公司通常會進行重組，導致業務流程和職責發生變更。在發生這些重組時，軟件並不會以同樣的方式發生改變，因此功能管理變得不清晰。之前由一個組織承擔的職責，現在需要兩個組織通過協作來定義需求和優先級。Evans拿這個與雙人三腿賽跑作對比，要想在雙人三腿賽跑中獲勝，參與者需要在速度和協調性之間找到平衡。一個不協調的團隊會輸掉比賽，但一個協調的很好但速度慢的團隊也不會贏。
他承認，近來DDD的復甦在很大程度上是由於微服務的興起，因此他認爲這是進行富有成效的對話的大好機會。Evans反駁了人們只是在追隨“微服務潮流”的觀點，他認爲，“微服務是打破障礙的攻城槌，在混亂中尋找機遇”。
“微服務是有邊界的上下文”這句話經常被提及，但這種說法過於簡單化了。Evans描述了微服務系統中的四種上下文類型:
- 在服務內部；
- 服務API；
- 服務集羣；
- 服務之間的交互。
隨着上下文類型的增加，我們也需要從狹窄和集中式的思維轉向更爲廣闊的架構視角。如果每個微服務都可以獨立定義一種用於跨系統通信的語言和消息，而不全盤考慮架構，那一定會出現混亂。
Evans還想要重新定義什麼是遺留系統，並讓人們能夠更有效地討論它們。Evans拿花園作爲比喻，一個新花園有很好的秩序感，但夏末的花園纔有“豐富的成熟度”，這就是花園的價值所在。類似地，開發人員和架構師應該以創建秩序爲目標播下種子，但也要欣賞成熟的系統中存在的豐富的混沌。
除了“遺留系統”，Evans提議可以用更多其他新的方式來分類和描述“成熟上下文”。在應用DDD時，需要理出系統的上下文和上下文之間的關係。確定成熟的上下文可以處理的枯燥職責，幫你與總是從頭開始的人性本能作鬥爭，就像一個成熟的花園已經富有成效一樣。Evans指出，反腐敗層是雙向的，它們保護新代碼不受遺留系統的影響，同時還會讓遺留系統不受新代碼的影響。
在處理被稱爲大泥球的系統的代碼時，需要注意的是，並不是系統的所有部分都設計得很好。一旦系統變得足夠大，你就無法回到整潔的世界。相反，我們的目標應該是從良好的邊界和隔離上下文從獲得好處。
原文鏈接：