[[404087]]

本文轉載自微信公眾號「逸言」，作者我是張逸。轉載本文請聯系逸言公眾號。

DDD的作用范圍主要還是針對系統級的分析、架構與設計，在更高的層面上，即將問題空間擴大到超過系統范圍，變成企業或組織范圍之后，DDD的模式就顯得捉襟見肘了。此時，可以考慮引入企業架構的思想，尤其是業務架構的內容，給了DDD很好的補充，又或者說，將企業架構與DDD融合起來，就能真正串聯起戰略和戰術設計了。

為什么在傳統企業中，DDD開始得到了許多企業的追捧?不僅僅是微服務的原因，就我個人不成熟的判斷，應該是數字化轉型開始倒逼著傳統企業的IT部門開始接納了DDD這一方法體系。

數字化轉型對企業的要求，表現在以下方面：

• 企業架構與行業的結合程度
• 數字化的企業IT架構

所謂“行業”，也可以理解為“領域”，傳統企業在互聯網經濟的沖擊下，開始向更快、更強的要求轉變，但真正的快，絕不是沒有規劃，恰恰相反，需要在戰略上有著清晰的轉型目標，而在戰術(企業的戰術層面，對應于DDD的戰略層次)上需要沉淀企業的領域資產。不管這些領域資產是通過核心模型、服務還是其他組件形式，都需要對準轉型方向的企業戰略，并在戰略指導下做到可復用業務能力的識別與沉淀。這個過程可以是計劃式的，也可以是演進式的;可以是分解為服務的粒度，也可以是能力中心的粒度;可以采用領域驅動設計建立核心領域模型，也可以建立自治的微服務，也可以是中臺的能力規劃與戰略。

數字化轉型必然不僅僅是業務的轉型，還包括IT架構的轉型。當前的一個趨勢是在基礎設施上，向著云原生架構轉變;在能力建設上，要改變組織模式，同時也要從項目思維向產品思維轉變;同時，還要加強對數據的重視，全面擁抱互聯網數據、物聯網數據，做到業務與數據的雙向支撐;在技術復用方面，也提出了前所未有的高要求，不管是PaaS、SaaS還是中臺的能力中心，或者微小粒度的服務與組件，更或者是近期炒得火熱的低代碼平臺，其核心關鍵還是遵循八二原則，盡可能將能夠復用的技術實現、業務模型(包括流程與規則)的開發成本降低，如此就能滿足快速開發產品服務不斷應對產品創新的需要，又能合理分配人力成本，花更多人力與物力去做好高價值的東西。

要做好企業的數字化轉型，就要“從企業整合運作、提升競爭力的角度出發，站在企業全局的高度，從理解企業所處行業、發展階段、目標、戰略、競爭環境等多方面入手，認清其核心能力及管理中存在的主要問題，在此基礎上進行管控模式分析，提出關鍵業務流程的優化建議”[引自《微服務設計：企業架構轉型之道》]，簡單說來，數字化轉型是企業層面的全面轉型，同時也是企業高管的思維轉型。為了規避風險，也為了企業的轉型步子能夠邁得更堅實，又需要根據輕重緩急分階段實施。實施的過程必然是自上而下的，但是隨著從頂層到底層的逐步細化，粒度也在不斷縮小，待縮小到目標系統的層次時，就是DDD登上舞臺的最佳時機了。

我曾經和多位業務架構師聊過企業架構與DDD的關系，竊以為企業架構在宏觀層面上有著自己一套成熟的體系方法，如TOGOF和Zachman等企業架構體系，它龐大的規范、標準與過程非常值得IT部門學習，值得將其引入到數字化轉型作為參考;然而，這些方法的問題在于：

• 過于復雜：雖然企業自身復雜度決定了體系的復雜性，但一套體系如果過于復雜，許多人窮其一生可能都無法掌握其全貌與細節，就很難掌控，更談不上落地;
• 過于宏觀：利用企業架構的思想和方法對企業做完戰略規劃后，如何保證方案的落地，又如何保證落地過程完全遵循解決方案的要求不偏不倚地推進，缺乏有效的手段。

企業架構就好似畫出了企業戰略規劃的模板，模板中的空白部分就是落地需要的知識和能力。利用業務架構，已經對這些模板與空白進行了有效的切分，并明確了各自的邊界，企業架構對業務架構向IT架構的映射給予了架構的指導，接下來，就可以通過DDD高質量地填充這些空白。

因此，企業架構與領域驅動設計是完全能夠融合在一起的，促進這一融合的催化劑是數字化轉型，呼喚這種融合的需求來自于相對高高在上的企業架構需要具備落地的能力，至于這種融合為何在現在開始提出或得到重視，是因為當下這個時代，具備了向這個趨勢發展的天時地利與人和：

• 天時：數字化轉型已經提上了大多數傳統企業的議事日程，不得不上，也必須上，而且得快上;
• 地利：各種IT基礎架構已經滿足了這一要求，無論是云原生、微服務、大數據，還是所謂的中臺，為這一融合打下了良好的基礎，敏捷思想已經深入人心，IT的管理能力與構建能力得到了大幅度的提高;
• 人和：數字化轉型讓企業高層領導看到了轉型的迫在眉睫，轉型的戰略規劃與IT架構構建已經時不我待，業務人士與IT人士都看到了這一趨勢，并開始打破業務與IT的壁壘，尋求全方位的合作。

如果說以上內容指出了這一融合趨勢，回答了融合的必要性，那么該怎么融合的問題就擺上了議事日程，畢竟二者并不處于同一層次，關心的角色也可能在身份地位上存在天壤之別。我的一個粗淺想法，是希望借鑒DDD的方法與思想，尋求對企業架構做必要的精簡和簡化，核心價值仍然是領域(業務)驅動，然后嘗試建立不同層次的架構體系，即建立組織級與系統級的架構，讓企業架構方法與DDD方法各司其職，組織級的棘手問題交給企業架構，系統級的落地問題交給DDD。

以上觀點很不成熟，個人對企業架構的認識也非常粗淺。從學習路線看，我算是自下而上的狂飆猛進，不再滿足于領域驅動設計的系統層次，要向上開始向企業頂層設計“逆襲”，之后，不是高高在上去俯視IT眾生，而是沉下心來，完成二者的真正融合——既要做得了規劃，還能寫得出方案，針對核心實現，還要能擼得出代碼。如此就算是打通業務(領域)驅動的任督二脈了!