The best architectures, requirements, and designs emerge from self-organizing teams.
當我們談到架構(gòu)的時候，往往我們忽略了軟件工程本身的復雜性，即系統(tǒng)中哪些部分是變化的，哪些是不變的。初中物理課上，老師告訴我們運動是永恒的，而靜止則是相對概念。同里，在不同時間維度上，“變化”是永恒的，“不變”是相對的。如果我們認為需求是不斷變化的，那么在軟件開發(fā)中，是否存在不變的東西呢？
在過去的一周中，花了兩天的時間引導客戶團隊一起做了一次領(lǐng)域驅(qū)動設(shè)計（DDD）工作坊。兩天的時間不長，從輸出的角度看，沒有完全將客戶系統(tǒng)的領(lǐng)域模型完整梳理出來。但是在這兩天的Workshop當中，我們從軟件架構(gòu)設(shè)計的角度，試圖找到一個軟件系統(tǒng)中的不變量。
參與工作坊的團隊成員在過程中向我提出一個問題：最終用戶能否作為領(lǐng)域?qū)＜覅⑴c到領(lǐng)域驅(qū)動設(shè)計的過程中。我把這個問題拋給了所有的聽眾來一起討論。討論的結(jié)果這樣闡釋了需求和領(lǐng)域的關(guān)系：
領(lǐng)域來自需求，但高于需求。相對于善變的用戶需求而言，領(lǐng)域知識和領(lǐng)域模型本身是“靜止”的，是“不變”的。
讓我們假想這樣一個需求：我們要開發(fā)一款圖書館管理軟件。客戶可能給了我們很多的需求，比如要一個統(tǒng)計功能，或者快速圖書查詢功能。恰好，客戶的團隊中可以為我們找到一位領(lǐng)域?qū)＜遥堅O(shè)想她（或他）在大學中學的是文獻管理專業(yè)，已經(jīng)在圖書館工作了幾十年，熟悉幾十年來圖書館的管理方式。她（或他）可以輕松的為你講解一本書從購入到借出、還回、入庫等一系列流程或?qū)I(yè)名詞，并且她（或他）清楚地知道為什么在“圖書館”這個上下文內(nèi)要有這樣一套流程；為什么這樣的管理方式是最適用于圖書館的。
這樣的領(lǐng)域?qū)＜覍嶋H上已經(jīng)“圖書館管理”這一領(lǐng)域進行過了足夠的抽象與總結(jié)，從而形成了完整的領(lǐng)域知識體系，也就是領(lǐng)域模型。
如果我們能夠找到這樣的領(lǐng)域?qū)＜遥退ɑ蛩┝囊涣模蛘呶覀冏揭黄鸾M織一個工作坊，將領(lǐng)域模型從專家的腦子中平移到紙面上。我們能獲得什么呢？我們得到的是只要“圖書館”這樣的組織存在，它為解決它領(lǐng)域的問題，而積累下來的領(lǐng)域解決方案。無論我們的系統(tǒng)“看起來”是什么樣的，無論我們的部署方式是單機部署還是云環(huán)境部署，領(lǐng)域內(nèi)的問題以及解決方案就是這個樣子。我們只需要將領(lǐng)域模型再次從紙面平移到軟件系統(tǒng)中，就可以完成整個核心領(lǐng)域?qū)拥臉?gòu)建。
有了領(lǐng)域模型，實現(xiàn)層面的用戶需求怎么辦？比如如何能更快速的找到統(tǒng)計頁面，如何能夠更好的向用戶展示數(shù)據(jù)，如何能方便用戶查詢。這些實現(xiàn)層面的需求相應(yīng)的解決方案，是和領(lǐng)域模型本身解耦的。而為了將領(lǐng)域?qū)油瑢崿F(xiàn)層建立起關(guān)系，我們需要引入應(yīng)用層，來實現(xiàn)關(guān)聯(lián)關(guān)系。
最后一個問題：領(lǐng)域模型在它自己的維度上如果是變化的怎么辦？此時此刻我很難想象一個合適的例子，因為領(lǐng)域模型本身的變化意味著領(lǐng)域解決方案的變化，也就意味著領(lǐng)域知識的變化。但針對這樣的可能性，我認為Bounded Context的存在，恰好可以解決一個不同領(lǐng)域間、或者同一領(lǐng)域下的子領(lǐng)域間解耦的問題，使得替換子領(lǐng)域模型變成可能。得到這樣的結(jié)論是因為我做了這樣的前提假設(shè)：
系統(tǒng)中領(lǐng)域模型的變化必然是漸進的。而這樣漸進的過程，必然是從某一個領(lǐng)域或子領(lǐng)域開始，繼而擴展到整個系統(tǒng)的。
如果這樣的前提假設(shè)為真，依據(jù)語義相關(guān)性及功能相關(guān)性來劃分的領(lǐng)域或子領(lǐng)域之間的松耦合關(guān)系，便是在軟件系統(tǒng)層面支撐領(lǐng)域模型演化的重要手段。
在這樣的“變”與“不變”共存的軟件系統(tǒng)開發(fā)中，如果我們想要輕松引入DDD的思路來做領(lǐng)域建模，找到一個像前文描述的那樣的領(lǐng)域?qū)＜沂侵匾獥l件。如果找不到這樣的領(lǐng)域?qū)＜遥珼DD的唯一途徑是通過開發(fā)團隊同客戶需求人員，或最終用戶代表的溝通，幫助他們實現(xiàn)領(lǐng)域建模。這樣做我們同樣可以獲得一個領(lǐng)域模型。
但在實踐中這樣的做法有一個致命的弱點：在領(lǐng)域模型抽象過程中，由于沒有領(lǐng)域?qū)＜业拇嬖冢瑘F隊非常容易脫離開領(lǐng)域統(tǒng)一語言本身，形成了一套抽象的“領(lǐng)域語言”，甚至“領(lǐng)域模型”。這樣的語言或者模型對于一個系統(tǒng)的擴展性和健壯性是有害的，同時也不能很好的體現(xiàn)DDD本身的優(yōu)勢。
寫了這么多，我的點在于，對于敏捷軟件開發(fā)而言，領(lǐng)域驅(qū)動設(shè)計對于系統(tǒng)架構(gòu)設(shè)計而言，能夠幫助我們識別出系統(tǒng)中相對穩(wěn)定的部分，從而提升對于變化部分“可變性”的支撐。而要想取得這樣的效果，需要團隊重視領(lǐng)域?qū)＜业拇嬖冢瑑A聽他們，和他們交流。因為一個軟件系統(tǒng)的存在的意義，仍然是要解決該領(lǐng)域中早已存在的問題。
