[[404087]]

本文轉(zhuǎn)載自微信公眾號「逸言」，作者我是張逸。轉(zhuǎn)載本文請聯(lián)系逸言公眾號。

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

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

數(shù)字化轉(zhuǎn)型對企業(yè)的要求，表現(xiàn)在以下方面：

• 企業(yè)架構(gòu)與行業(yè)的結(jié)合程度
• 數(shù)字化的企業(yè)IT架構(gòu)

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

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

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

我曾經(jīng)和多位業(yè)務(wù)架構(gòu)師聊過企業(yè)架構(gòu)與DDD的關(guān)系，竊以為企業(yè)架構(gòu)在宏觀層面上有著自己一套成熟的體系方法，如TOGOF和Zachman等企業(yè)架構(gòu)體系，它龐大的規(guī)范、標(biāo)準(zhǔn)與過程非常值得IT部門學(xué)習(xí)，值得將其引入到數(shù)字化轉(zhuǎn)型作為參考;然而，這些方法的問題在于：

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

企業(yè)架構(gòu)就好似畫出了企業(yè)戰(zhàn)略規(guī)劃的模板，模板中的空白部分就是落地需要的知識和能力。利用業(yè)務(wù)架構(gòu)，已經(jīng)對這些模板與空白進(jìn)行了有效的切分，并明確了各自的邊界，企業(yè)架構(gòu)對業(yè)務(wù)架構(gòu)向IT架構(gòu)的映射給予了架構(gòu)的指導(dǎo)，接下來，就可以通過DDD高質(zhì)量地填充這些空白。

因此，企業(yè)架構(gòu)與領(lǐng)域驅(qū)動設(shè)計是完全能夠融合在一起的，促進(jìn)這一融合的催化劑是數(shù)字化轉(zhuǎn)型，呼喚這種融合的需求來自于相對高高在上的企業(yè)架構(gòu)需要具備落地的能力，至于這種融合為何在現(xiàn)在開始提出或得到重視，是因為當(dāng)下這個時代，具備了向這個趨勢發(fā)展的天時地利與人和：

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

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

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