Thoughtworks-軟件行業(yè)：換個角度認識軟件

/thoughtworks理解軟件背后的生意34透過領(lǐng)域建?？窜浖墓窍?3換個角度看架構(gòu)87把團隊看作分布式系統(tǒng)105在軟件開發(fā)過程中，比較難的一件事就是如何表達需求、之所以會出現(xiàn)這類表達問題，一部分原因是我們對邏輯的理解不同。大多數(shù)有經(jīng)驗的開發(fā)者、系統(tǒng)分析師都具備一定的辯證思維和方法，要說誰沒有邏輯，這件事情很難說得過去。如果每個人都是用自己的思維方式和“邏輯”，讓溝通過程變得非常困難。令我疑惑的是，每個人都相信邏輯是很重要的，但幾乎沒有文章討論過在軟件設(shè)計和開12有些開發(fā)者認為“設(shè)備”是現(xiàn)實中看得見摸得“設(shè)備”。于是，他們在溝通時經(jīng)常會出現(xiàn)對于“設(shè)備”3在咨詢的工作中，我發(fā)現(xiàn)非常有意思的是，將軟件中的概念一一定義清楚，整個系統(tǒng)的設(shè)計工作差不多就完成了。所以設(shè)計軟件的過程和現(xiàn)實中人們相互交流非常類似。英當我們描述事物的時候?qū)嶋H上就是將有清晰邊界的元素貼正是因此不同語言之間準確地翻譯也不太可能1，不同文化背景難以找到合適的概念互相映射。后來哲學(xué)家認識到人們認識概念是由一些更為基礎(chǔ)的屬性構(gòu)成的，那可以認這些基本的屬性又是一些更基本的概念，如果我們對這些類似于面向?qū)ο笳Z言Java中的類，類有各種屬性，這些譯之可能與不可能――對翻譯問題的哲學(xué)思考.4因此屬性是認識概念非常重要的一方面。屬性包含了事物自身的性質(zhì)、行為，比如黑白、高矮、是否能飛行、是否獨立行走。事物除了自身的性質(zhì)外，還與其他事物發(fā)生一通過屬性就能找到概念的邊界。具有相同屬性的概念是同例如，土豆和馬鈴薯都是同一個概念。如果意識不到屬性對概念的影響，則會出現(xiàn)生活中的命名錯誤，例如小熊貓一個概念可以具有多種表達方法，對于軟件設(shè)計來說，我們可以用自然語言描述概念。也可以通過定義一個類來描述，并在程序運行時實例化這個概念。通過數(shù)學(xué)或者數(shù)理5自然語言中，商品是指可以通過貨幣或者其他物品交易的物品，可以是自然實體，也可以是虛擬物品。這是社會經(jīng)濟中對商品的描述，商品具有一個核心屬性就是價格，有自然語言（NaturalLanguage）就是人類講的語言，它是這類語言不是經(jīng)過特別設(shè)計的，而是通過自然進化的。它的特點是語法規(guī)則只是一種規(guī)律，并非需要嚴格遵守的規(guī)則，這種語言含有大量的推測，以及對話者本身的認知背景（比如東西方不同的文化背景形成了大量的哩語）。認?從概念上說，白馬這個概念不是馬這個概念，所以?從謂詞（“是”這個謂詞）邏輯來說，白馬這個概念代表的事物集合屬于馬這個概念代表的事物集合。6所以白馬是馬（白馬屬于馬，但是白馬這個概念不在邏輯學(xué)中，形式語言開始發(fā)揮作用。形式語言（FormalLanguage）是指用精確的數(shù)學(xué)或機器可處理的公式定義的語言。例如數(shù)學(xué)家用的數(shù)字和運算符號、化學(xué)家用的分子式等，以及編程語言中的一些符號（Token）。計算機編程也是一種形式語言，是專門用來表達計算過程的形式總之，知道形式語言和自然語言之間的區(qū)別，可以避免無意義的爭論。軟件工程師就是一個對現(xiàn)實業(yè)務(wù)形式化的工正因為如此，需求和溝通的矛盾不可能避免，除非提出需求的人也使用形式語言，那么軟件工程師的價值也就沒有7使用形式語言可以精確地定義一個概念，并使用精確的語如果通過計算機語言來描述一個概念，其實就是面向?qū)ο髉ublicpublicclassItem{privateStringname;privateBigDecimalprice;}ItemItem{name,price}計算機語言和數(shù)學(xué)語言是一種形式化的語言，可以精確地描述一個概念，但是自然語言只能通過模糊地給出概念的描述。自然語言翻譯成計算機語言的不確定性，帶來了無正是因為自然語言的這種模糊性，為了更加具體地描述一個概念。哲學(xué)上概念的共識是，概念有兩個基本的邏輯特征，即內(nèi)涵和外延。概念反映對象的特有屬性或者本質(zhì)屬例如商品這個概念的內(nèi)涵是“能進行交換的產(chǎn)品”，本質(zhì)屬性是能進行交換，從本質(zhì)上區(qū)別產(chǎn)品。它的外延就是投對概念外延的清晰描述對我們設(shè)計軟件產(chǎn)品的定位非常有幫助，我們購買軟件服務(wù)無非兩種情況，生活娛樂使用，生活資料。這其中的邏輯完全不同，按照生活資料的邏輯概念的內(nèi)涵和外延在一定條件下或者上下文中被確定的，這取決于參與人的共識。嚴格鎖定概念的內(nèi)涵和外延，能幫助我們討論問題和改進軟件模型。隨意修改內(nèi)涵和外延。9外延就會縮小，概念就會變得越具體。當內(nèi)涵縮小時，外這在面向?qū)ο筌浖Ｖ械挠绊懛浅Ｃ黠@。對象特有屬性或者本質(zhì)屬性越少，那么這個對象能被復(fù)用的場景越多，也就是內(nèi)涵越小。反之，特有屬性越多，能被復(fù)用的情況就越少了。軟件建模過程中隨意修改概念往往意識不到，但是每一次屬性的添加和移除都帶來概念的內(nèi)涵和外延發(fā)非常典型的一個例子發(fā)生在訂單模型中。一般來說，我們會把支付單和訂單分開設(shè)計，訂單的概念中沒有支付這個行為，但有時候覺得支付單的存在過于復(fù)雜，會將支付單內(nèi)涵和外延發(fā)生變化但是設(shè)計人員沒有意識到，會使用同一個詞語。一旦使用同一個詞語就會產(chǎn)生二義性，二義性的存在對軟件建模是致命性打擊。比如用戶維護的地址、地址庫中的地址、訂單中的地址，這三個“地址”雖然名意識不到概念的內(nèi)涵和外延，是無法設(shè)計出邏輯良好的軟變量命名實際上就是為一個概念進行定義。定義是揭示概念內(nèi)涵和外延的邏輯方法，而一個準確的定義需要反映出對象的本質(zhì)屬性或特有屬性。在下定義時，存在兩個常見對于第一個困難，邏輯學(xué)有一些很好的下定義方法，可以屬加種差定義法。這種下定義的方法通俗來說就是先把某一個概念放到另一個更廣泛的概念中，邏輯學(xué)中將這個大的概念叫做“屬概念”，小的概念叫做“種概念”。從這個屬概念中找到一個相鄰的種概念，進行比較，找出差異化本質(zhì)屬性，就是“種差”。比如，對數(shù)學(xué)的定義，數(shù)學(xué)首先是一門學(xué)科，和物理學(xué)處于同類，它的本質(zhì)屬性是研支付單是一種反映用戶完成某一次支付行為的憑據(jù)。屬概物流單是一種反映管理員完成某一次發(fā)貨行為的憑據(jù)。屬對于第二個痛點，這不是軟件建模能解決的問題，需要充分和領(lǐng)域?qū)＜矣懻摚@取足夠的業(yè)務(wù)知識。人們對概念的定義或者認識是隨著對事物的認識不斷加深而變化的。一個完全對某個領(lǐng)域沒有基本認識的軟件工程師很難做出合理的軟件建模，例如銀行、交易所、財會等領(lǐng)域的軟件需我們做消費者業(yè)務(wù)的互聯(lián)網(wǎng)開發(fā)時，往往因為和我們的生活相關(guān)，所以這種感受并不明顯。當做行業(yè)軟件時，領(lǐng)域如果需要建立邏輯思維，還需要一些邏輯規(guī)律。邏輯學(xué)的三個基本規(guī)律可以讓溝通更加準確，避免無意義的爭論，減少邏輯矛盾，讓討論有所產(chǎn)出。這三個重要的規(guī)律是：在同一段論述（命題和推理）中使用的概念含義不變，這比如論題是“網(wǎng)絡(luò)會讓人的生活更美好嗎？”，兩個主要假如我們選擇的論點是“網(wǎng)絡(luò)讓人們的生活更方便”。在辯論賽中，我們陳述了“沒有網(wǎng)絡(luò)非常不方便”，反方被誘導(dǎo)描述了“打電話、寫信也可以讓人生活很美好，不一這剛好落入我們的邏輯陷阱。我們指出，郵政、電話網(wǎng)絡(luò)矛盾律應(yīng)用得更為普遍，幾乎所有人都能認識到矛盾律。矛盾律這個詞的來源就是很有名的“矛和盾”的典故，出自《韓非子?難勢》中。說有一個楚人賣矛和盾，牛吹得過大，說自己的盾在天底下沒有矛能刺破，然后又說自己的矛，天底下的盾沒有不能穿透的。前后矛盾是一個眾所周知的邏輯規(guī)律，但是并不是一開始馬上就能看出來，需具有矛盾的論述有時候又被稱為悖論。尤其是宗教領(lǐng)域充滿了大量的悖論，例如，是否存在一個萬能的神，做一件在軟件開發(fā)過程中，我們時常遇到這種情況，需要在開發(fā)過程中才能發(fā)現(xiàn)矛盾。我們常常會接到一些充滿矛盾的需“在多用戶空間系統(tǒng)中，用戶可以被禁用并且可以加入多個空間。用戶所屬空間的管理員有權(quán)禁用用戶。即使用戶上面提出了一個矛盾的業(yè)務(wù)需求：空間管理員可以修改用需求提出者并沒有理清用戶本身和空間成員之間的關(guān)系。在需求評審過程中，我們經(jīng)常會發(fā)現(xiàn)這種矛盾，并通過解排中律是邏輯規(guī)律中最難理解的一個規(guī)律。它的表述是：同一個思維過程中，兩個互相否定的思想必然有一個是真排中律的意義在于，明確分析問題的時候不能含糊其辭，從中騎墻。比如有人討論：人是不是動物。不能最終得到比如在一次技術(shù)會議中，需要選擇使用的數(shù)據(jù)庫，只能使用一種數(shù)據(jù)庫。如果采用了MySQL就不能說沒有采用MySQL。排中律看起來好像沒有意義，卻是一項重要的邏輯原則，模型這個詞常常會聽到，通常出現(xiàn)在某個PPT或者一篇商V型圖、四象限會以各種形式出現(xiàn)在不同場合中；軟件工程師的模型會更加形式化，UML、E-R圖等，能用較為精確的形式語言描述；數(shù)學(xué)模型就更加精確，馬爾可夫、蒙廣義來說這些都叫模型，甚至是你隨手在白板上畫的一個用來解釋當前程序結(jié)構(gòu)的圖形，通過這種方式表達思維框架。哲學(xué)家?guī)於鲗⑦@種思維框架叫做范式，也就是模型?！坝靡粋€較為簡單的東西來代表另一個東西，這個簡單的“用一個較為簡單的東西來代表另一個東西，這個簡單的東西被叫做模型。”我們天生就有用簡單的東西代表另外一個東西的能力，比如幼兒園數(shù)數(shù)用的竹簽，學(xué)習物理時的剛體、真空中的球形雞，都是模型。通俗來說模型就是經(jīng)驗的抽象集合，平1.模型是簡化的。正是因為我們要認識的事物非常復(fù)雜，因此需要通過簡化找出最一般的規(guī)律，才能一語中的?！疤靾A地方”學(xué)說就是最簡單的古人認識世界的模型之一；毛主席的“階級劃分論”簡單、2.模型是邏輯的。例如用金字塔原理描述社會階層，每層的定義是明確的而非模糊的，數(shù)學(xué)模型能用數(shù)學(xué)符號系統(tǒng)和公式描述，模型中的元素能用一種邏3.模型是錯誤的。因為模型是一種抽象，所有的模型都是錯誤的，只能在一個方面反映事物的特征。場景變了，模型就需要修正，連牛頓、愛因斯坦的定的情況下較好地擬合事物，完全匹配現(xiàn)實的模型就并從觀察到的情況中采樣，轉(zhuǎn)換成具體的數(shù)字，得2.信息。信息是數(shù)據(jù)中反映出能被人類理解的內(nèi)容，將信息中的一般規(guī)律找出來，建立模型。比如某地區(qū)降雨量和年度呈現(xiàn)一定相關(guān)性，建立一個周期性4.智慧。面對不同情況需要使用不同的模型和修正模型的能力，并能用它指導(dǎo)實踐，比如根據(jù)周期性降我整理了一個圖表，說明了一款軟件從商業(yè)探索開始，到團隊管理模型項目管理模型(瀑布、敏捷)20我將模型分為形式化和非形式化兩種。形式化的模型是精確描述的模型，例如表達領(lǐng)域模型的UML、ER圖，而非對于應(yīng)用開發(fā)的軟件工程師來說，核心的問題并非如何編寫代碼，而是如何將非形式化的業(yè)務(wù)輸入（模型）進行合在多年以前，計算機科學(xué)家們認為編寫Java代碼的人不算程序員，可以由業(yè)務(wù)人員直接編寫業(yè)務(wù)軟件。由于軟件工程中非形式化和形式化之間存在一個巨大的鴻溝，編程就是模型的形式化過程，從這個角度看能深刻分析業(yè)務(wù)并獲得良好抽象結(jié)果的程序員具有競爭力，即便我們有了ChatGPT，分析業(yè)務(wù)和建模的工作也不會被它替代。在非形式化模型這一步，實際上又存在兩種模型。一種是描述軟件背后的生意，即使不使用計算機系統(tǒng)參與到業(yè)務(wù)中，該如何完成交易，并讓企業(yè)獲得利潤，我把它叫做商業(yè)模型。另一種是描述軟件的操作和交互的模型，關(guān)注參除此之外，還有一些模型和計算機工作原理相關(guān)的模型，這是計算機科學(xué)家的工作，對于普通開發(fā)者來說可以加深對計算機的理解。例如，符合人類的認知的編程語言（面將這些模型串起來，能夠提高對軟件工程的理解，以及每個部分背后的邏輯，明白這些模型背后的目標后可以更加從容地應(yīng)對各種問題。限于篇幅本章討論計算機科學(xué)中的如今，計算機已經(jīng)發(fā)展到一種近乎魔法般的存在。對于非計算機專業(yè)畢業(yè)的從業(yè)者而言，理解計算機和編程語言的原理以及面向?qū)ο笏枷胱兊美щy。然而，我們可以尋找一22從算盤到計算機，人類走過了漫長的歷史。計算機發(fā)展的轉(zhuǎn)折點往往都是一些大師提出關(guān)鍵模型的時期，了解這些他們把計算機當作一種可以通過編程語言對話的“生物”來看待了。我曾被問到過，我們?nèi)粘Ｊ褂玫摹半娔X”為何要回答這個問題需要將圖靈和馮諾依曼模型兩個計算機科算盤會被經(jīng)常和計算機一起提到，算盤是人力驅(qū)動的一種計算機，算珠的狀態(tài)可以看作寄存器。對中國人來說理解算盤的狀態(tài)為初始狀態(tài)，每一次撥動算珠就是一個指令，當所有的指令下發(fā)完成，算盤上最終狀態(tài)就是計算結(jié)果。在算盤之后的時代，還有計算尺，甚至手搖計算機。手搖23式計算機算是一種半自動的計算機，我國科研人員曾使用并提出了計算機的抽象模型。在論文《論可計算數(shù)及其在判定問題中的應(yīng)用》中，圖靈提出了著名的理論計算機抽象模型――“圖靈機”。它描述了這樣一種機器：一個虛擬的機器，由一條無限長的紙帶和讀寫頭組成。紙帶上分布有連續(xù)的格子，并能被移動、讀寫。機器能讀取一個指令序列，指令能對格子紙帶進行移動和讀寫。和算盤的邏輯一樣，機器每執(zhí)行一個圖靈模型只是描述了一步一步地完成計算任務(wù)，這種機器諾依曼?，F(xiàn)代的計算機實際上是一個死循環(huán)，可以類比為沖程發(fā)動機，才讓計算機看起來有了生命。這才有了我們ENIAC是公認第一個滿足圖靈模型的計算電子計算機，24ENIAC通過紙帶編寫程序，并撥動開關(guān)執(zhí)行和獲得結(jié)果。述了另外一種模型，他認為程序本質(zhì)上也是一種數(shù)據(jù)，將指令和數(shù)據(jù)共同存放到內(nèi)存中，這些指令中存在特殊的跳存儲程序模型構(gòu)建了一個能自我運行計算模型，構(gòu)成了一個系統(tǒng)。處理器和內(nèi)存之間使用總線連接，用來給這個系統(tǒng)提供輸入的設(shè)備叫做外設(shè)，每一次指令循環(huán)可以訪問一想象一臺由繼電器組成的計算機，如果每一次執(zhí)行指令計線性地嘚嘚嘚……嘚嘚?！?。馮?諾依曼的模型就是上電后嘚嘚嘚嘚嘚……中斷……嘚嘚嘚嘚嘚”，并反復(fù)循環(huán)。25CPU ?數(shù)據(jù)流指令流馮?諾依曼進一步抽象了算法也是數(shù)據(jù)，進而讓計算機無各種各樣的編程語言層出不窮，由于工作的需要，我們會接觸不同的編程語言。如何能理解編程語言的本質(zhì)是什么呢？我嘗試找一些模型簡化對編程語言的理解。先用矛盾計算機只能識別機器指令和人類難以使用機器指令解決具所以人類設(shè)計出來各種各樣符合人類習慣（各不相同）的26方式編寫程序，這些編寫程序的模型就是高級語言。要使用自己定義的語法規(guī)則來寫程序，就需要一個轉(zhuǎn)換器，能所以編譯器是一個自動推理機，只要能被推理的形式化語言都可以作為輸入。除了自然語言無法實現(xiàn)之外，無論用編譯的過程有：語法分析、詞法分析、語義分析、中間代碼和優(yōu)化、目標代碼。大師通過編譯過程學(xué)習如何實現(xiàn)編譯器，普通工程師可以反過來用這個過程理解一門新的語我嘗試將編譯過程中的環(huán)節(jié)找到一個現(xiàn)實中的類比來理解編譯器，將其類比為人類閱讀法律文書（法律文件是最貼處理調(diào)查材料，案件人員、行為等要素將Token組織為一棵樹(AST)用于推理將人員和行為映射成圖譜，用于識別行為發(fā)生的動機、背景，提上面三步是前端，中間代碼是為了多平臺根據(jù)不同的平臺進行輸出到報紙、網(wǎng)28我嘗試找到一些通俗的模型理解編譯過程，/a-map-of-the-territory.html理解編譯器后再學(xué)編程語言就清晰很多，比如語法2.句法（Syntax）：決定一個句子是否合法，比如流3.語義（Grammar決定一段代碼的組織結(jié)構(gòu)是否Lexical和Syntax往往可以看成一體，Grammar不太一樣，在一些編譯器中Syntax和Grammar的錯誤提示都不太一樣。所以可以這樣看一門語言：Syntax是類C的還是非類C的，Grammar上是面向?qū)ο蟮睦斫馔评砟Ｐ涂梢杂脕韼椭鷮W(xué)習編程語言，比如TypeScript可以編譯成JavaScript，很多時候我們不需29要特別學(xué)習TypeScript，將小段TypeScript代碼編譯一下，看看生成的JavaScript是什么就行了。有了自動推理機，可以將人們定義的語法轉(zhuǎn)換成機器代碼的語法規(guī)則。讓我們有了方法、變量、條件、循環(huán)等這些面向過程的語言依然還是圖靈模型解決問題的思路：有限的有序指令序列。只不過這里的指令從機器語言、匯編代碼換成了容易理解的表達式而已，面向過程的編程語言和組織面向過程的程序，這部分工作的心智負擔需要高水平的程序員來完成，將現(xiàn)實中的業(yè)務(wù)分解成有限的有序指令序列。分解任務(wù)成為指令序列的過程就是編程，它要求程序員既要像人一樣思考現(xiàn)實又要像機器一樣思考。像機器一樣思考需要最聰明的人來完成才行，好的程序員可不好能不能想辦法利用推理機，再進一步，讓程序員按照人類30一樣思考事物，寫出符合人類語義的代碼，然后再翻譯成目標代碼呢？回答這個問題就需要先回答另外一個問題，人類需要通過概念來進行交流，給一撮物質(zhì)一個標簽，這個標簽就是概念。將一堆便簽夾起來再打上標簽，就是抽象概念。不同的語言、不同文化背景的人無法交流就是因為使用了不同的標簽系統(tǒng)，甚至也有可能標簽貼錯了的情要理解面向?qū)ο缶幊蹋枰缴钪腥ビ^察小孩玩泥巴的情景。他們用泥巴創(chuàng)造出一個城堡，而泥土就好像計算機我們?yōu)榱嗣枋鲞@類對象，就給它們起個名字以便交流。類可以對應(yīng)現(xiàn)實中的一個概念，但很多面向?qū)ο缶幊痰臅梢园熏F(xiàn)實和面向?qū)ο笾械脑貙Ρ纫幌?，建立一個理解類人所以面向?qū)ο缶幊淌墙⒃诜浅：玫男闹悄Ｐ蜕系?，只不實體、類、行為，這些面向?qū)ο笾械膬?nèi)容和概念早已經(jīng)被人是通過語言思考的，我們不遺余力地使用自然語言描述事物，面向?qū)ο笫怯嬎銠C語言和自然語言的一座橋梁，這座橋梁由哲學(xué)連接。對象這個詞在不同的領(lǐng)域都被用到，32維特根斯坦的《邏輯哲學(xué)論》中對對象、類的闡述和面向?qū)ο笫侨苏J識世界的基本單位，對象由實體和正在發(fā)生的也就是說對象不是一成不變的，可以由“造物主”自由地設(shè)計和組合。當我們在開發(fā)一款XXX管理系統(tǒng)時，被管理假設(shè)我們正在開發(fā)倉儲管理系統(tǒng)，極端的面向?qū)ο笳邥嬖V你將行為放到“貨物”這類實體中，這樣看起來更加像虛擬的世界里，靜態(tài)的對象需要由動態(tài)的對象處理構(gòu)成了一組主客體關(guān)系。而對于“上帝”來說，它們都是對象。33熟悉Java的程序員可以這樣理解，Spring中的Bean是一種對象，在應(yīng)用啟動時就被初始化了，就像上帝造出亞當開始干活兒。而從數(shù)據(jù)庫中提取出來的實體，就像是從如果開發(fā)一款游戲，對象貌似都是有生命的。但是對于普銀員”這類對象，而“貨物”這類實體就應(yīng)該讓它們安安34理解軟件背后的生意需求變化是軟件工程師最難以容忍的一件事，為了做好軟首先我們不得不承認，從客觀上講軟件它是有區(qū)別于硬件的，為什么叫軟件，因為它本身就是能改的，并且修改的成本低于硬件。硬件涉及電路設(shè)計、制版、開模等流程，在開發(fā)的過程當中，需求變化會帶來巨大的成本。這是為35什么軟件能夠提高效率的原因，因為通過軟件搭建在通用計算機平臺上，能夠很快做出業(yè)務(wù)應(yīng)用和實現(xiàn)。通用軟件的出現(xiàn)，軟件開發(fā)和硬件開發(fā)分離是信息社會的一個關(guān)鍵對于軟件來說，修改并不是沒有成本的，只是相對硬件而言小了許多。對軟件工程師來說，業(yè)務(wù)的變化往往會帶來困擾，因為它會讓軟件的架構(gòu)設(shè)計和模型的建立變得非常但并不是所有的軟件需求變化，我們都不能接受。對于一些軟件的交互和界面UI樣式等這些細節(jié)上面的修改不影響主體的業(yè)務(wù)變化，這種修改是沒有任何問題的。我們說的軟件需求變化帶來的困擾指的是在軟件開發(fā)過程中隨意變更軟件的邏輯，讓軟件的整體性和邏輯性受到了破壞，對于專業(yè)的產(chǎn)品經(jīng)理來說，軟件的修改是非常謹慎的，因36那么在軟件開發(fā)和迭代的過程當中，我們可能難以意識到造成項目的延期，這是開發(fā)團隊人員不喜歡軟件被修改的如果我們對軟件的需求進行分層，我們可以把軟件所存在最底層是軟件所存在的業(yè)務(wù)價值，或者是通俗來說它是前面提到的“軟件的生意”。我們在構(gòu)建一個點餐軟件、構(gòu)建一個電商軟件、構(gòu)建一個物流軟件，那么軟件幫我們做的事情就是取代原來傳統(tǒng)商業(yè)活動中人需要做的事情。提高這些行為的效率，為社會創(chuàng)造更多的價值，這些軟件背那么在這層軟件需求之上的，是我們軟件的架構(gòu)。軟件的架構(gòu)承載了生意或者商業(yè)模式，可以看做軟件的骨骼。比如說電商里面就有訂單等這些關(guān)鍵的模型，或者一些慣用模式。類比起來就相當于我們?nèi)梭w的一個骨架或者建筑物37還有一些是軟件的一些具體的邏輯細節(jié)，比如說約束電商系統(tǒng)確認收貨時間是多少天。軟件這些業(yè)務(wù)規(guī)則，就像人體的血肉一樣，豐富了軟件。業(yè)務(wù)規(guī)則填充了軟件的一些交互邏輯細節(jié)，讓軟件工程師在不修改主體結(jié)構(gòu)的情況下去，改這些邏輯細節(jié)，有時候并不是非常困難的，軟件工還有一種軟件的需求，就是軟件的交互方式和UI樣式，這些就好像動物的皮膚。不具備特別的功能性，而是負責軟件的"肉"軟件的"骨"軟件的軟件的"魂"38修改這個軟件的難度，會呈指數(shù)上升，不亞于重新設(shè)計一對于創(chuàng)業(yè)公司來說，他們的業(yè)務(wù)架構(gòu)和生意，或者說它的對于成熟的公司來說，軟件是這個公司業(yè)務(wù)流程的沉淀，業(yè)務(wù)流程可能不會發(fā)生特別大的變化，比如說銀行、保險或者財會，這些特定的業(yè)務(wù)流程基本上已經(jīng)形成了行業(yè)的規(guī)范或者標準。他們的變化情況不會特別大，那么軟件的架構(gòu)也就不容易受到破壞，重大的業(yè)務(wù)需求變化就會非常一個能夠在市場上存活的軟件，一定有它背后的業(yè)務(wù)邏輯和業(yè)務(wù)價值。那么我們從底層出發(fā)，找到了一個軟件的業(yè)39務(wù)價值，也就是它的生意，我們就可以快速地理解軟件的其次，我們可以真正地挖掘出業(yè)務(wù)分析師或產(chǎn)品經(jīng)理希望的業(yè)務(wù)?；谲浖r值模型，軟件背后的邏輯和生意總是存在的，但是產(chǎn)品經(jīng)理不一定能夠用自己的語言或合適的對于軟件工程師來說，只有兩個選擇。要么給自己的軟件的架構(gòu)設(shè)計提供足夠的靈活性，這也是很多軟件設(shè)計思想計”，在特定的環(huán)境下，軟件的競爭力被削弱。一個有靈活或者彈性的軟件架構(gòu)，背后是付出一定的代價，但往往另外一個選擇就是真正地理解軟件背后的生意，通過軟件價值模型的啟示從變化中找到不變。因此我們不得不將視野從軟件本身返回到軟件承載的業(yè)務(wù)上，為了理解這些業(yè)那么軟件工程師理解軟件的路徑為：理解商業(yè)→理解業(yè)務(wù)40如果我們理解了軟件背后的生意，可以更加從容地設(shè)計軟件。更為重要的是，和需求提出者的交流更加容易，除非需求提出者也并不熟悉正在設(shè)計的軟件背后承載的商業(yè)目分析一個企業(yè)的商業(yè)模型方法非常多，下面介紹比較常見也比較簡單的方法――商業(yè)模式畫布。最早來源于亞歷山大.奧斯特瓦德的《商業(yè)模式新生代》一書。其主要的思想是，商業(yè)模式不應(yīng)該由幾百頁的商業(yè)策劃書來描述，而是應(yīng)該由一頁紙就能清晰地呈現(xiàn)。根據(jù)思維經(jīng)濟性原則，無法清晰表述的商業(yè)模式其價值也值得8重要合作KeyPartners7關(guān)鍵業(yè)務(wù)KeyActivities2價值主張ValueProposition4客戶關(guān)系CustomerRelationship1客戶細分CustomerSegmenets6核心資源KeyResources 3渠道通路ChannelsCostStructureRevenueStream編寫商業(yè)模式畫布實際上是需要回答9個問題，弄明白如果投資人看這份商業(yè)模式畫布，才能快速知道這筆生意使用商業(yè)模式畫布來研究商業(yè)模式的案例非常多，這些案很多人可能和我一樣對拼多多有一些疑惑，為什么在電商42格局已經(jīng)充分競爭后，依然還有崛起的機會？我們不妨用1.客戶細分（CS，CustomerSegments）如果不加以區(qū)分客戶和用戶，我們很容易得到拼多多的客戶是普通的消費者。實際上從財務(wù)的角度，如果消費者的每一筆消費都算在拼多多的收入中，那么拼多多需要支付拼多多的業(yè)務(wù)旨在幫助小微企業(yè)、農(nóng)戶和個人快速開設(shè)店鋪，并從中獲得傭金。因此，在客戶這一側(cè)和淘寶網(wǎng)的初由于天貓的存在和戰(zhàn)略因素，阿里電商在這個領(lǐng)域相當薄2.價值主張（VP，ValuePropositions）關(guān)于價值主張這部分我一直比較疑惑，拼多多到底能提供43在一份名為《“電商黑馬”拼多多的商業(yè)模式探析》1的報告中，提到了拼多多價值主張為“免去諸多中間環(huán)節(jié)，實現(xiàn)C2M模式，提供物有所值的商品和互動式購物體驗的“新電子商務(wù)”平臺。C2M為（Customer-to-Manufacturer，用戶直連制造）但是這個模式并不新鮮，一些分析者將拼多多的模式總結(jié)為物找人。通過拼單的方式，先定義物品，再通過社交媒體找到需要的目標群體。從價值主張上說，拼多多的價值和其他主流、非主流電商3.渠道通路（CH，Channels）在價值主張上，各種電商平臺差距非常小，無非都是“消除中間商，降低流通成本”。但是在細分領(lǐng)域，渠道通路的競爭非常明顯，甚至有些電商平臺將自己的電商屬性隱1邱柳方.“電商黑馬”拼多多的商業(yè)模式探析[J].國際商務(wù)財會,2021(11):34-37+41.44例如，以社交抹茶美妝、小紅書、Keep這些產(chǎn)品的電商屬性非常弱，實際上是通過社交渠道強化了電商的渠道能力。拼多多的渠道是建立在一種病毒營銷的模式上的，俗4.客戶關(guān)系（CR，CustomerRelationships）拼多多的店鋪分為了幾類2，不過最終還是可以分為專業(yè)類（企業(yè)或個體工商戶店）和普通類。專業(yè)類的客戶為具普通類的無需保證金和工商材料即可開店，而正是普通類5.收入來源（RS，RevenueStreams）根據(jù)財報顯示（2021年數(shù)據(jù)），拼多多的收入來源為在線市場服務(wù)和少量的自營商品銷售，財務(wù)來源并沒有特殊6.核心資源（KR，KeyResources）在商業(yè)模式和收入來源都沒有特殊的情況下，拼多多的核心資源是什么呢？在一些商業(yè)分析中，將拼多多的核心資2參考拼多多商家入駐說明/qualifications45源歸結(jié)為用戶流量。截至2021年第一個季度結(jié)束，拼多多年活躍買家數(shù)達8.238億3，那么這些買家是從哪里來7.關(guān)鍵業(yè)務(wù)（KA，KeyActivities）8.重要合作（KP，KeyPartnership）拼多多的合作伙伴有：騰訊微信、物流企業(yè)、電視媒體。換句話說，商家是賺消費者的錢，拼多多是賺商家的錢。并將流量轉(zhuǎn)化為商家的客源，可以看做是微信的用戶群體9.成本結(jié)構(gòu)（CR，CostStructure）拼多多的成本結(jié)構(gòu)主要是市場推廣費用，其次是管理費用3數(shù)據(jù)來源/k/20220527A0AG730046根據(jù)商業(yè)模式畫布分析，拼多多的商業(yè)模式主要是以獨特的營銷推廣為基礎(chǔ)，為小微企業(yè)和個體農(nóng)商戶促成交易。在交易渠道上借助了微信騰出的渠道真空（微信渠道對淘寶不開放，拼多多和京東無太多競爭關(guān)系，騰訊為拼多多的第二大股東）。從其營收結(jié)構(gòu)主要為在線市場傭金收入通過商業(yè)模式畫布可以理解企業(yè)的商業(yè)模式，弄明白在企業(yè)的業(yè)務(wù)中誰是客戶，收入從哪里來，合作伙伴是誰等。不過，商業(yè)模式畫布沒有將企業(yè)的內(nèi)部運轉(zhuǎn)結(jié)構(gòu)打開，一個企業(yè)需要運轉(zhuǎn)起來，需要各個部分之間的通力合作，并要明白地表達企業(yè)內(nèi)部各方的合作情況，業(yè)務(wù)服務(wù)藍圖可在兩種流派和方法：一種是使用兩張圖來表達，這樣能看47應(yīng)用服務(wù)藍圖；另外一種流派是將其繪制到一張圖上，統(tǒng)業(yè)務(wù)服務(wù)藍圖本質(zhì)上是一種流程圖，表達商業(yè)中各個參與的主體（參與業(yè)務(wù)的各個部門可以看做業(yè)務(wù)主體）之間的往來，通過多個泳道來表達參與的業(yè)務(wù)主體。服務(wù)藍圖在“服務(wù)設(shè)計”這個概念下可以看做是用戶旅程的延伸。在服務(wù)藍圖中，不僅包含水平方向的客戶服務(wù)過程，還包括以蔬菜配送為案例，我們來看下服務(wù)藍圖的應(yīng)用。我還原了一個真實的小本買賣――某批發(fā)市場的食材配送公司的然后通過電話下訂單給某家配送公司的客戶經(jīng)理，客戶經(jīng)好在我虛擬的這家配送公司自建了物流，出庫和配送是一48交互線交互線個部門，否則還需要新的契約來滿足配貨出庫和物流之間當餐廳收到貨物后，食材配送公司一般會出具一張清單，餐廳清點完成后需要簽字蓋章。這張單據(jù)往往會被用來作為處理糾紛的關(guān)鍵單據(jù)，而糾紛的發(fā)生會比想象中多非常在具有固定合作關(guān)系的商業(yè)主體之間，往往都不會結(jié)算現(xiàn)款，都有一定的結(jié)算周期，通過結(jié)算單來完成結(jié)算，隨之餐廳老板食材清單食材訂單可售清單收貨單資金憑證結(jié)算單客戶營銷部倉配部支持部門49如果理解了一個企業(yè)的商業(yè)模式，以及支持了支持商業(yè)模式的業(yè)務(wù)，再來看構(gòu)建在兩者之上的信息系統(tǒng)或者軟件就我們可以做一個思維實驗，一家主營食材配送的企業(yè)，它的客戶是餐廳老板，公司的主要業(yè)務(wù)為每日清晨為各個餐廳配送食材。毫無疑問在現(xiàn)代化的社會，信息系統(tǒng)必然是存在的。這家公司使用了微信作為渠道，建立了小程序、H5應(yīng)用建立了食材訂購的應(yīng)用，同時又為承擔配送工作的員工開發(fā)了具有送貨、打單功能的安卓原生APP，以及假定在某天系統(tǒng)故障了，但是配送的工作不能停下來，這是事關(guān)商譽的事情。如果因為一次無理由的斷供，會導(dǎo)致相關(guān)的餐廳無法營業(yè)，營業(yè)中斷帶來的損失遠遠超過當天貨物的價值。于是，公司領(lǐng)導(dǎo)無論如何都需要想辦法將食材送到客戶手中。在信息系統(tǒng)無法使用時，它們可能的做法是，從數(shù)據(jù)庫導(dǎo)出備份的數(shù)據(jù)，打印出來，人工通知到客戶。我們會發(fā)現(xiàn)，對于這類軟件，完全可以使用紙和筆這種思維實驗，也是也是在軟件設(shè)計時常用的方法。當業(yè)50務(wù)復(fù)雜，產(chǎn)品經(jīng)理或者業(yè)務(wù)人員無法描述清楚，我們可以斷電法，可以將系統(tǒng)中晦澀難懂的概念在現(xiàn)實中找到可以被理解的物品。比如，用戶這個概念比較抽象。餐廳老板或者經(jīng)理可以作為用戶在配送平臺上下單，如果斷電了，那么用戶在現(xiàn)實中是什么呢？可能是食材配送老板大腦中烤鴨店張老板老板需要預(yù)定烤鴨店張老板老板需要預(yù)定100斤大蔥，打電話給食王老板：原來是老張啊，今天需要什么貨呢。（根據(jù)……難度，更容易理解業(yè)務(wù)。前面的業(yè)務(wù)服務(wù)藍圖可以看做是對于行業(yè)軟件來說，軟件技術(shù)本身并不復(fù)雜，它更像是一個“機器人”（軟件），難在如何教會這個機器人像專業(yè)有軟件參與的服務(wù)藍圖，我們可以叫做應(yīng)用服務(wù)藍圖。意味著，我們找到了“電子幫手”，電子幫手會參與到業(yè)務(wù)個主體可以幫助業(yè)務(wù)完成更高效的工作。在前面食材配送的例子中，微食材（這里設(shè)定出來的產(chǎn)品名稱）會參與到52食材訂單資金憑證食材清單可售清單收貨單結(jié)算單交互線客戶營銷部倉配部支持部門53通過對軟件業(yè)務(wù)模型的分析，對業(yè)務(wù)領(lǐng)域進行建模就能獲得軟件的邏輯結(jié)構(gòu)。獲得了軟件的邏輯結(jié)構(gòu)就能進一步指導(dǎo)服務(wù)劃分、數(shù)據(jù)庫設(shè)計、API設(shè)計等技術(shù)實踐。沒有領(lǐng)域模型設(shè)計的軟件，工程師往往會過多地關(guān)注到技術(shù)問題領(lǐng)域建模對于商業(yè)軟件來說是非常重要的一環(huán)，也是工程54領(lǐng)域驅(qū)動設(shè)計(DDD)1是EricEvans提出的一種軟件設(shè)計實際上DDD的概念和邏輯本身并不復(fù)雜，很多概念和名詞是為了解決一些特定的問題才引入的，并和面向?qū)ο笏枷爰嫒?，可以說DDD也是面向?qū)ο笏枷胫械囊粋€子集。我們先把DDD這些概念丟開，從一個案例出發(fā)，在必要讓我真正對計算機軟件和建模有了更深入的認識是在一家餐廳吃飯的時候。數(shù)年以前，我還在一家創(chuàng)業(yè)公司負責餐飲軟件的服務(wù)器端的開發(fā)工作，因為工作的原因，外出就餐時常都會對餐廳的點餐系統(tǒng)仔細觀察，以便于改進我們1參考圖書：《領(lǐng)域驅(qū)動設(shè)計――軟件核心復(fù)雜性應(yīng)對之道》/subject/2681966655對我們的就餐并沒有什么影響。我突然很好奇這家店，在收銀系統(tǒng)無法工作的情況下怎么讓業(yè)務(wù)繼續(xù)運轉(zhuǎn)，因此我故事的發(fā)展并沒有超出預(yù)期，服務(wù)員拿了紙和筆，順利地完成了點餐，并將復(fù)寫紙復(fù)寫的底單麻溜地撕下來交給了我這時候才回過神來，軟件工程師并沒有創(chuàng)造新的東西，只不過是數(shù)字世界的磚瓦工，計算機系統(tǒng)中合乎邏輯的過就是軟件設(shè)計的基本邏輯。如果我們只是關(guān)注于對數(shù)據(jù)庫的增、刪、改、查（CRUD），實際上沒有對業(yè)務(wù)進行正會計、餐飲、購物、人員管理、倉儲，這些都是各個領(lǐng)域抽象成計算機系統(tǒng)中對象并存儲。這就是DDD和面向?qū)?6現(xiàn)實是，我們往往馬上關(guān)注到數(shù)據(jù)庫的設(shè)計上，想當然地設(shè)計出一些數(shù)據(jù)庫表，然后著手于界面、網(wǎng)絡(luò)請求、如何操作數(shù)據(jù)庫上，業(yè)務(wù)邏輯被封裝到一個叫做Service對象我要一份魚香肉絲寫入-條訂數(shù)據(jù)我要一份魚香肉絲服務(wù)員餐飲系統(tǒng)一般來說這種方法也沒有大的問題，甚至工作得很好，MartinFowler將這種方法稱作為事務(wù)腳本（Transaction數(shù)據(jù)存儲作為一個“模塊”，可以實現(xiàn)用戶拖拽就可以實現(xiàn)簡單的編程，.net、VF曾經(jīng)提供過這種設(shè)計模式，這種設(shè)計模式叫做SMARTUI。57?非常直觀，開發(fā)人員學(xué)習完編程基礎(chǔ)知識和數(shù)據(jù)庫雖然最終都是對數(shù)據(jù)庫的修改，但是中間存在大量的業(yè)務(wù)邏輯，并沒有得到良好的封裝。客人退菜，并不是將訂單中的菜品移除這么簡單。需要將訂單的總額重新計算，以由于沒有真正的“訂單”對象負責執(zhí)行相關(guān)的業(yè)務(wù)邏輯，初學(xué)者程序員擅自修改數(shù)據(jù)片段，破壞了整體業(yè)務(wù)邏輯。Service上的一個方法直接修改了數(shù)據(jù)庫，業(yè)務(wù)邏輯的完58剩下的菜不要了，結(jié)賬!剩下的菜不要了，結(jié)賬!但收銀員劃掉菜品后沒有更新小計，另外的服務(wù)員結(jié)賬時刪除菜品訂單異常服務(wù)員餐飲系統(tǒng)我們決定，抽象出訂單、菜品的對象，菜品不應(yīng)該被直接修改，而是通過訂單才能修改，無論任何情況，菜品的狀復(fù)雜系統(tǒng)的狀態(tài)被清晰地定義出來了，Service承擔處理59在接觸EricEvans的DDD概念之前，我們沒有找到這種剩下的菜剩下的菜不要了，結(jié)賬!服務(wù)員服務(wù)員刪除菜品持久化訂單持久化訂單通過模型維護業(yè)務(wù)一致性餐飲系統(tǒng)從上面的例子中，模型是能夠表達系統(tǒng)業(yè)務(wù)邏輯和狀態(tài)的對業(yè)務(wù)進行充分的抽象，找出這些隱藏的模型，并搬到系統(tǒng)中來。如果發(fā)生在餐廳的所有事物，都要能在系統(tǒng)中找60通過對實際業(yè)務(wù)出發(fā)，而非馬上關(guān)注數(shù)據(jù)庫、程序設(shè)計。通過識別出固定的模式，并將這些業(yè)務(wù)邏輯的承載者抽象到一個模型上。這個模型負責處理業(yè)務(wù)邏輯，并表達當前我們做的計算機系統(tǒng)，實際上是替代了現(xiàn)實世界中的一些現(xiàn)實餐廳中的實體，應(yīng)該對應(yīng)到我們的系統(tǒng)中去，用于承載業(yè)務(wù)，例如收銀員、顧客、廚師、餐桌、菜品，這些虛后來，如果我什么業(yè)務(wù)邏輯想不清楚，我就會把電斷掉，分析業(yè)務(wù)場景系統(tǒng)設(shè)計和實現(xiàn)分析業(yè)務(wù)場景系統(tǒng)設(shè)計和實現(xiàn)分析業(yè)務(wù)，設(shè)計領(lǐng)域模型，編寫代碼。這就是領(lǐng)域驅(qū)動設(shè)計的基本過程。領(lǐng)域模型設(shè)計好后（通俗來說，領(lǐng)域模型），?指導(dǎo)RESTfulAPI設(shè)計。訂單訂單提煉領(lǐng)域模型商品用戶在我們之前的例子中，收銀員需要負責處理收銀的操作，同時表達這個餐廳有收銀員這樣的一個狀態(tài)。收銀員收到62錢并記錄到賬本中，賬本負責處理記錄錢的業(yè)務(wù)邏輯，同我們進行業(yè)務(wù)系統(tǒng)開發(fā)時，大多數(shù)人都會認同一個觀點：但是實際開發(fā)過程中，我們既要分析業(yè)務(wù)，也要處理一些使用領(lǐng)域驅(qū)動設(shè)計還有一個好處，我們可以通過隔離這些技術(shù)細節(jié)，先進行業(yè)務(wù)邏輯建模，然后再完成技術(shù)實現(xiàn)，因為業(yè)務(wù)模型已經(jīng)建立，技術(shù)細節(jié)無非就是響應(yīng)用戶操作?技術(shù)復(fù)雜度。軟件設(shè)計中和技術(shù)實現(xiàn)相關(guān)的問題，?業(yè)務(wù)復(fù)雜度。軟件設(shè)計中和業(yè)務(wù)邏輯相關(guān)的問題，63例如為訂單添加商品，需要計算訂單總價，應(yīng)用折業(yè)務(wù)復(fù)雜性業(yè)務(wù)復(fù)雜性技術(shù)復(fù)雜性基礎(chǔ)設(shè)施API接口當我們分析業(yè)務(wù)并建模時，不要關(guān)注技術(shù)實現(xiàn)，因為會帶來極大的干擾。和上一章聊到的斷電法理解業(yè)務(wù)一樣，就是在這個過程把“電”斷掉，技術(shù)復(fù)雜度中的用戶交互想該只是實現(xiàn)軟件的工程師自嗨。業(yè)務(wù)專家是一個虛擬的角由于和業(yè)務(wù)專家一起完成建模，因此盡量不要選用非常專業(yè)的繪圖工具和使用技術(shù)語言?？梢钥闯鯠DD只是一種64建模思想，并沒有規(guī)定使用的具體工具。我這里使用PPT很熟悉UML也是可以的。甚至實際工作中，我們大量使用便利貼和白板完成建模工作，好處是一屋子的人方便參這個建模過程可以是技術(shù)人員和業(yè)務(wù)專家一起討論出來，也可以使用“事件風暴”這類工作坊的方式完成。這個過計，我們得到了領(lǐng)域模型（這里以簡單的圖表表示，也可NN一個座位可以關(guān)聯(lián)多個訂單，每個訂單可以有多個菜品和65我們用領(lǐng)域模型驅(qū)動的方式開發(fā)軟件系統(tǒng)，相對于事務(wù)腳有一天，市場告訴我們，這個系統(tǒng)會有一個邏輯問題。就是系統(tǒng)中菜品被刪除，訂單也不能查看。在我們之前的認這里的菜品存在了致命的二義性這里的菜品實際上?在菜品管理中，價格為30元的魚香肉絲，包含菜單菜品管理中的菜品下架后，不應(yīng)該產(chǎn)生新的訂單，同時也不應(yīng)該對訂單中的菜品造成任何影響。這些問題是因為，技術(shù)專家和業(yè)務(wù)專家的語言沒有統(tǒng)一，DDD一書提到了這個問題，統(tǒng)一語言是實現(xiàn)良好領(lǐng)域模型的前提，因此應(yīng)66該“大聲地建?！薄Ｎ以趨⑴c這個過程目睹過大量有意義1N和現(xiàn)實生活中一樣，產(chǎn)生二義性的原因是我們的對話發(fā)生在不同的上下文中，我們在談一個概念必須在確定的上下文中才有意義。在不同的場景下，即使使用的詞匯相同，但是業(yè)務(wù)邏輯本質(zhì)都是不同的。想象一下，發(fā)生在《武林67這段對話中實際上有三個上下文，這里的“菜”這個詞出.大嘴說去買菜，這里的菜應(yīng)該被理解為食材，如果68掌柜對這個菜進行管理，應(yīng)該具有采購者、名稱、?秀才說實習生把賬單中的菜算錯了價格，秀才需要對賬單進行管理，這里的菜應(yīng)該指的賬單科目，現(xiàn)?老白的客人點了一只醬鴨，但老白關(guān)注的是訂單下的訂單項。訂單項包含價格、數(shù)量、小計、折扣等實際上，還有一個隱藏的模型――上架中商品。掌柜需要添加菜品到菜單中，客人才能點，這個商品就是我們平時69N11NN111N圖9領(lǐng)域模型v3在被虛線框起來的四個區(qū)域中，我們都可以使用“菜品”這個詞匯（盡量不要這么做），但是大家都知道“菜品”具有不同的含義。這些區(qū)域被稱為上下文。當然，上下文不僅僅是由二義性決定的，也可能是由完全不相關(guān)的概念當我們討論座位時，我們完全在談?wù)撈渌虑椋虼俗蛔R別上下文的邊界是DDD中最難的一部分，同時上下文70 邊界是由業(yè)務(wù)變化動態(tài)變化的，我們把識別出邊界的上下文叫做限界上下文（BoundedContext）。限界上下文是一個非常有用的工具，限界上下文可以幫助我們識別出模限界上下文的識別難以有一個明確的準則。上下文的邊界非常模糊，需要有經(jīng)驗的工程師并充分討論才能得到一個好的設(shè)計。同時需要注意，限界上下文的劃分沒有對錯，只有是否合適?？缦藿缟舷挛闹g模型的關(guān)聯(lián)有本質(zhì)的不11NN11N1NN11NN11使用上下文之后，帶來另外一個收獲。模型之間本質(zhì)上沒有多對多關(guān)系，如果有，說明存在一個隱含的成員關(guān)系，這個關(guān)系沒有被充分分析出來，對后期的開發(fā)會造成非常上面的模型，尤其是解決二義性這個問題之后，已經(jīng)能在實際開發(fā)中很好地使用了。不過還是會有一些問題沒有解決，實際開發(fā)中，每種模型的身份可能不太一樣，訂單項必須依賴訂單的存在而存在，如果能在領(lǐng)域模型圖中體現(xiàn)訂單項的存在必須依賴于訂單的存在。這樣業(yè)務(wù)邏輯是一致的和完整的，游離的訂單項對我們來說沒有意義，除非為了解決這個問題，對待模型就不再一視同仁了。我們將相關(guān)性極強的領(lǐng)域模型放到一起考慮，數(shù)據(jù)的一致性必須解決，同時生命周期也需要保持同步，我們把這個集合叫72聚合中需要選擇一個代表負責和全局通信，類似于一個部門的接口人，這樣就能確保數(shù)據(jù)保持一致。我們把這個模型叫做聚合根，聚合根充當一組領(lǐng)域模型領(lǐng)航員的角色。當一個聚合業(yè)務(wù)足夠簡單時，聚合有可能只由一個模型組在聚合中，無論是否是聚合根，對于有自己的身份（ID）1N1N1N1N11N1N1N1我們把這個圖完善一下，聚合之間也是用虛線連接，為聚73?聚合根本質(zhì)上也是實體，同屬于領(lǐng)域模型，用于承?聚合根負責和其他聚合通信，因此聚合根往往具有還有一類特殊的模型，這類模型只負責承載一組字段值的表達，沒有自己的身份。在我們飯店的例子中，如果需要對賬單支持多國貨幣，我們將純數(shù)字的price字段修為Price類型。publicclassPricepublicclassPrice{privateStringcurrency;privateBigDecimalvalue;publicPrice(Stringcurrency,BigDecimalvalue){this.currency=currency;this.value=value;74}}}價格這個模型，沒有自己的生命周期，一旦被創(chuàng)建出來就無須修改，因為修改就改變了這個值本身。所以我們會給我們把沒有自己生命周期的模型，僅用來呈現(xiàn)多個字段的值對象一開始不是很容易理解，但是理解之后會讓系統(tǒng)設(shè)75地址中的某一個屬性不應(yīng)該被單獨修改，因為被修改之后這個“地址”就不再是剛剛那個“地址”，判斷地址是否最簡單的理解，值對象就是“屬性包”，就是一些自己定義的通用拓展類型，持久化時展開到數(shù)據(jù)庫表或者存為JSON字符串。另外值得一提的是，一個模型被作為值對象還是實體看待不是一成不變的，某些情況下需要作為實體設(shè)計，但是在?作為訂單中的收貨地址時，無須進行管理，只需要表達街道、門牌號等信息，應(yīng)該作為值對象設(shè)計。?在進行系統(tǒng)地理位置信息管理時，其具有自身的生命周期，因此應(yīng)將其作為實體進行設(shè)計，并將其重76我們使用淺色表達值對象以便區(qū)別于聚合根和實體，更新N1N11N11雖然我們使用E-R的方式描述模型和模型之間的關(guān)系，但是這個E-R圖使用了顏色（如果是黑白印刷的紙質(zhì)版可能看不到具體的顏色，可以自行體會）、虛線，已經(jīng)77和傳統(tǒng)的E-R圖大不相同，把這種圖暫時叫做CE-R圖（ClassifiedEntityRel何畫圖，你可以使用其他任何畫圖的方法表達領(lǐng)域模型，如果需要嚴謹一點可以采用UML的類圖繪制（推薦使用在《領(lǐng)域驅(qū)動設(shè)計》一書中，Eric闡述了領(lǐng)域驅(qū)動設(shè)計的重要性和一些基本實踐，但并沒有給出具體的建模過程方法。這為架構(gòu)師提供了很大的發(fā)揮空間，可以使用各種建于是有一些朋友會產(chǎn)生疑惑，這些建模方法背后的邏輯是什么呢，它們有沒有什么共通之處？這里和大家一起探討軟件建模過程方法的基本邏輯，以及如何設(shè)計一套簡單的目前進行領(lǐng)域建模方法使用得最多的是事件風暴。事Gamestorming，通過工作坊的方式將領(lǐng)域?qū)＜液图夹g(shù)專2Eventstorming網(wǎng)站/78它先從事件開始分析，捕獲事件。然后分析引發(fā)事件的行EventStorming的邏輯是什么？為什么需要先從事件開始我?guī)е@些問題請教了很多專家，甚至發(fā)送了郵件給AlbertoBrandolini，有幸得到回復(fù)。根據(jù)AlbertoBrandolini的理解，他認為系統(tǒng)中事件是一種容易尋找到系統(tǒng)詞匯法（OOA）系統(tǒng)詞匯法就是面向?qū)ο蠓治龇椒?。這種面向?qū)ο蠼５姆椒ū容^原始和直接，直接通過經(jīng)驗提取領(lǐng)域模型，就是1.首先，從需求陳述中找出所有的名詞，將它們作為“類―對象”的初步候選者。去掉不正確和不必要79的對象（不相關(guān)的、外部的和模糊的對象），作出2.為上一步的模型作出定義，構(gòu)建數(shù)據(jù)字典，描述對系統(tǒng)詞匯法建模的優(yōu)點和缺點都比較明顯。優(yōu)點是沒有過多的建模過程，對于簡單的系統(tǒng)有經(jīng)驗的架構(gòu)師馬上就能觀察出合適模型。相應(yīng)地，缺點也很明確，沒有對業(yè)務(wù)充用例模型是一種需求分析模型，是需求分析后的一種輸出Jacobson中提出了用例的概念和可視化的表示方法用例用例（UseCase）是對一個活動者使用系統(tǒng)的一項功能時80用例由參與者、關(guān)系、用例三個基本元素構(gòu)成，用例圖的參與者用例2.從用例中提取出名詞，作為備選模型，這個時候不3.找動詞，通過動詞和用例關(guān)系分析模型之間的關(guān)聯(lián)4.對名詞進行抽象、展開，把用例中作為屬性的名詞由于用例圖從不同的參與者出發(fā)，因此非常適合表達業(yè)務(wù)行為，可以避免錯誤的復(fù)用。在很長一段時間里，很多軟件架構(gòu)師都依賴用例圖來建立模型。用例分析法的特點是不容易遺漏，但缺點是由于名詞的二義性，往往會設(shè)計出四色建模法其實是以數(shù)據(jù)驅(qū)動，通過挑選一些關(guān)鍵數(shù)據(jù)（類似于辦事過程中的存根），來還原整個業(yè)務(wù)流程。然（description）。1.以滿足業(yè)務(wù)運營的需要為原則，尋找需要追溯的業(yè)2.基于這些業(yè)務(wù)事件發(fā)生的存根，建立時標性對象，824.最后把描述的信息放入描述對象，附著在需要補充四色建模法由PeterCoad提出3，其實并不是一種流的建模方式，其原因為存根和時標性對象在很多業(yè)務(wù)系事件風暴相對其他的建模方法非常獨特，所以放到最后來1.尋找事件。事件（Event）是系統(tǒng)狀態(tài)發(fā)生的某種客觀現(xiàn)象，事件格式參考“XXX已YYY”，比如“訂3關(guān)于四色建模法來源見文章/article/xh-four-color-modeling83業(yè)務(wù)用例，是某個場景中領(lǐng)域事件的觸發(fā)動作，執(zhí)3.尋找模型。為了在這個階段保持和業(yè)務(wù)專家的良好5.劃分限界上下文。對模型進行劃分，在戰(zhàn)略上將模事件風暴在獲得模型的深刻性上具有優(yōu)勢，但是在操作上更為困難。另外由于它不從用例出發(fā)，和四色建模一樣，在計算機領(lǐng)域中，關(guān)于元模型的研究資料和書籍較少，因《本體元建模理論與方法及其應(yīng)用》一書介紹了如何建立84通過對這些方法的總結(jié)，我們可以嘗試建立一個簡單的建其實，面向?qū)ο笾械哪Ｐ褪乾F(xiàn)實世界在計算機系統(tǒng)中的一種比喻，類似的比喻還有函數(shù)式等其他編程范式。對于現(xiàn)實世界的分析，我們可以使用認識論建立一個非常簡單的主體：主體是有認識能力和實踐能力的人，或者是在客體：客體是實踐和認識活動所指向的對象，是存在系統(tǒng)詞匯-85系統(tǒng)詞匯---在認識論中，每一個客觀現(xiàn)象的出現(xiàn)，都可以使用主體、客體來分析。找到導(dǎo)致這個客觀現(xiàn)象的行為背后的主體、客體，就能清晰地描述事件，也更容易看到問題的本質(zhì)。從認識論的角度出發(fā)，建模的過程就是找到確定的客體作從這個表中我們可以看出，系統(tǒng)詞匯法的建模線索不夠清86執(zhí)行者作為業(yè)務(wù)主體，在系統(tǒng)中發(fā)出了一個命令作為業(yè)務(wù)事件風暴是從事件、命令和執(zhí)行者為線索推導(dǎo)出模型，整87什么是軟件架構(gòu)？通俗來說，軟件架構(gòu)就是將軟件中合適的組件放到合適的地方，這就讓軟件架構(gòu)變成了一種混合軟件架構(gòu)是關(guān)于軟件整體結(jié)構(gòu)和組件的抽象描述，用于指88除此之外，還需要有一些原則來指導(dǎo)具體的實施，類似于施工規(guī)范和標準。在設(shè)計軟件架構(gòu)時，會做出大量的決策才能得出最終的元素和關(guān)系。然而，我們不需要馬上作出所有細致入微的決策，只需要先作出后續(xù)難以調(diào)整的決策即可。正如維特根斯坦所說“世界是一切發(fā)生的事情”，架構(gòu)中的元素有可能用不同的視角來表達的，也有可能具有層級結(jié)構(gòu)，于是我們往往通過圖形化的方式來描述和表達，也就成了傳說中的“PPT工程師”。89從復(fù)雜和混亂的信息中找到重點才能定義出元素以及找到關(guān)系。架構(gòu)是一個非常玄學(xué)的領(lǐng)域，它不像編寫一個確定系統(tǒng)熵越多，沒有能量輸入時，系統(tǒng)逐步趨向復(fù)雜、無序本質(zhì)復(fù)雜度是在解決問題時，無法避免的事；偶然復(fù)雜度1.在軟件項目中，隨著參與人數(shù)的增加，溝通節(jié)點也會增多，從而導(dǎo)致信息節(jié)點的增加，偶然復(fù)雜度也2.信息噪音過多，就像信息論描述的那樣，當噪音太902.分而治之，將復(fù)雜度隔離到局部，讓局部的復(fù)雜性PPT是復(fù)雜信息的索引PPT的真正作用是復(fù)雜性管理，這也是微軟幻燈片軟件PowerPoint的寓意來源。據(jù)說Gaskins在給PowerPoint起名字時，最初在洗澡時迸發(fā)的靈感，想到的名字中包含了這個詞。而且在不知情的情況下，他的同事GlennHobin在機場的海報中，一眼看到了PowerPoint這個被一套架構(gòu)用的匯報材料，可能就是某個復(fù)雜系統(tǒng)一份極好而且還需要具備非常強的表現(xiàn)能力，把方案清晰地表現(xiàn)出上下游系統(tǒng)上下游系統(tǒng)技術(shù)棧和工具DEVOPS來?；脽羝瑘D表并非只是展示，更像是一個索引來描述復(fù)應(yīng)用網(wǎng)關(guān)層服務(wù)層回咨詢師2咨詢者管理員云和基礎(chǔ)設(shè)施優(yōu)秀的架構(gòu)師、咨詢師都能作出好的幻燈片，有時候甚至幻燈片就是一種很好的概念模型，這樣想就應(yīng)該能把幻燈片重視起來。沒有好的思維結(jié)構(gòu)，就做不出幻燈片，想到的不一定能表達出來，所以幻燈片做得好的人具有特別的簡化和克制的圖才是真正有用的圖，因為保留的有效信息更為突出，將龐大無比的系統(tǒng)簡化到幾張A4能夠被打印92水平分層b迭代演進水平分層b迭代演進分而治之不能降低復(fù)雜性，只能隔離復(fù)雜性。而分而治之1.水平分解。對系統(tǒng)進行分層，下層對上層透明，上2.垂直分解。對系統(tǒng)進行按模塊（上下文）切割，上下文之間不需要關(guān)心彼此，只有在有互相依賴的情3.按時間分解。對系統(tǒng)的實現(xiàn)分步驟完成，根據(jù)迭代演進，制定產(chǎn)品、架構(gòu)路線圖（RoadMa夠夠不v1.0v2.0v3.093注意區(qū)分廣為流傳的AFK拓展立方體，AFK拓展立方體對于系統(tǒng)設(shè)計來說，每一個版本我們可能都會進行垂直、水平分解得到一張平面的架構(gòu)圖，在持續(xù)演進的狀態(tài)下不這就印證了我們前面說的架構(gòu)的過程是一切決策之和。架構(gòu)決策的影響有時候遠遠被我們低估，有時候我們的決策由于對具體分層的定義非常模糊，導(dǎo)致了我們實際上分了互聯(lián)網(wǎng)通信依賴的網(wǎng)絡(luò)協(xié)議TCP/IP是一個非常經(jīng)典的分層模型，因為全球網(wǎng)絡(luò)是一個經(jīng)典的分布式系統(tǒng)，實際上94我們無論在設(shè)計哪種形態(tài)的分布式架構(gòu)時，都可以參考網(wǎng)我們在學(xué)習TCP/IP或者OSI分層網(wǎng)絡(luò)時會使用一個常見的“郵差”比喻，來形象地描述網(wǎng)絡(luò)協(xié)議的原理，其中就Montreal需要寄送一封信，她在信的結(jié)尾寫上字作為落款，然后通過郵局將其寄出。郵局進一步包裝并貼上郵局的標簽，將信件發(fā)送到運輸公司。運輸公司將其裝箱，并通過不同的交通工具將其遞送到目標站點，并發(fā)送到目標郵局，也就是他們在目的地的客戶那里。最終，3.運輸層：物流公司通過不同的交通工具運輸貨物的95有時候，我們僅僅通過行為來描述分層很難說清楚分層是什么，比如郵局和物流公司的分層在某些情況下可能說不AlicedropsAlicedropsofbothatthedeliverybasedonthestreetandpersonalnames.postofcepostofcepostofcielooksattheadresses(citynames!!!andarrangesforpropertransportation圖片來源：https://www.eecs.yorku.ca/course_archive/2010-11/F/3213/CSE3213_03_LayeredArchitecture_F2010.pdf96任何一個行為都能找到它的操作者以及身份，也就是行為的主體，也能找到操作的內(nèi)容，也就是行為的客體。我們可以通過分析主體、行為、客體三個要素來辨析分層之間的關(guān)系。這樣讓分層更加明確。如果能在該層找到明確的主體對象、客體對象，以及說明其關(guān)系，我們就能將其說攬收寄件，并打運輸貨物，裝箱通過主體的明確和客體的明確，主體之間的職責會清晰地浮現(xiàn)出來，主體的權(quán)責更加清晰，我們細心分析也會發(fā)現(xiàn)這種分層也是社會化分工的體現(xiàn)。主體的性質(zhì)是截然不同97的，郵局、攬收點作為法律主體時，一般不是以自然人的性質(zhì)出現(xiàn)的。另外物流公司這類主體往往也需要額外的資這是現(xiàn)實中的分層思想，那么在軟件中是不是這樣的呢？假設(shè)以后端業(yè)務(wù)系統(tǒng)的經(jīng)典三層結(jié)構(gòu)，我們來看下它的分Controller層ControllerRequest/ResponseService層ServiceRepository層Repository化數(shù)據(jù)/SQL用主客體來分析，MVC模型如果沒有Service時，只能算兩層，因為Model只是客體（忽略Model和其屬性之間的主客關(guān)系），構(gòu)不成完整的一層。Service、Repository層都有對應(yīng)的主客體關(guān)系，能夠說清楚它的權(quán)98如果按照網(wǎng)絡(luò)協(xié)議的分層設(shè)計，下層是不需要知道上層的信息或者知識的，也就是說理想的情況下Repository層的客體應(yīng)該是無差別的數(shù)據(jù)才對。所以我們可以看到JPA型信息。當我們無法實現(xiàn)出無差別的Repository層時，2.下層需要盡可能地提供無差別的能力給到上層，讓那么通過辨析主客體的關(guān)系，就能提高代碼的表達力，尤其是在命名上。所以對客體起名的關(guān)鍵在于定義這個客體的概念，使用擬物的方式起名。對主體的起名需要定義它99servicetoprotocolwithpeerLayerNLayerNservicetoprotocolwithpeerLayerNLayerNservicefromLayerN-1IPv6ICMPv6802.11wirelessLANFrameRelayATM方法，賓語：參數(shù)，補語：返回值）的方式編寫代碼，讓服務(wù)劃分的目的是垂直分解復(fù)雜性。這里的“垂直”指的是在某一層內(nèi)的垂直。因此，不同層之間垂直劃分的粒度Layer7LayerNLayer1TCP/ProtocolSuiteHTTPFTPSMTPTCPUDPICMPARPIP(IPv4)Ethernet圖片來源：https://www.eecs.yorku.ca/course_archive/2010-11/F/3213/CSE3213_03_LayeredArchitecture_F2010.pdf100在很多系統(tǒng)的垂直劃分時最大的誤區(qū)是穿透了分層，想象一下我們有一套自己的通訊協(xié)議，這套通訊設(shè)備同時具備了應(yīng)用層、網(wǎng)絡(luò)層、傳輸層、數(shù)據(jù)鏈路層，那么這套通訊協(xié)議就很難被歸納到TCP/IP協(xié)議簇中實際上水平分層比垂直分層要簡單很多，因為我們很容易技術(shù)類的垂直劃分實際上比較簡單的，比如接入層，如果有兩種物聯(lián)網(wǎng)設(shè)備接入?yún)f(xié)議，我們很容易將其根據(jù)協(xié)議類型劃分開。這是因為計算機科學(xué)家在這些領(lǐng)域有充分的解但是業(yè)務(wù)服務(wù)的垂直劃分就非常麻煩了，特別是沒有經(jīng)歷過沉淀的創(chuàng)新類軟件系統(tǒng)。以企業(yè)通訊軟件為例，企業(yè)通訊錄、群組、用戶這幾個概念若即若離，無論是劃分開、還是合并到一起都會有不少的麻煩，有時候甚至沒有完美性質(zhì)類似但是職責范下面這張圖為互聯(lián)網(wǎng)收銀系統(tǒng)的分層架構(gòu)，水平的方向使用了同樣的背景色，他們的性質(zhì)基本類似。假設(shè)這個系統(tǒng)以非常理想的方式設(shè)計，接入層為不同的網(wǎng)絡(luò)接入方式，但是對于應(yīng)用層來說，如何清晰地界定哪些屬于應(yīng)用，需要對產(chǎn)品設(shè)計有非常深刻的理解，以及和產(chǎn)品經(jīng)理達成共識。對于領(lǐng)域?qū)觼碚f，如何找出相對獨立的能力單元也不是那么容易（當我們把領(lǐng)域邏輯和應(yīng)用邏輯分開后，領(lǐng)域webSCketHTTPHTTP接入?yún)f(xié)議MQTTservicebMQTTPacket后臺應(yīng)用運營管理應(yīng)用orderservice聚合order上下文上下文orderltemuserlnfoshopcartservicewebSCketHTTPHTTP接入?yún)f(xié)議MQTTservicebMQTTPacket后臺應(yīng)用運營管理應(yīng)用orderservice聚合order上下文上下文orderltemuserlnfoshopcartserviceorderRepositoryMQ客戶端Redis客戶端數(shù)據(jù)庫客戶端、ORM網(wǎng)絡(luò)邊界(前端請求)網(wǎng)絡(luò)邊界(基礎(chǔ)設(shè)施)網(wǎng)絡(luò)邊界(基礎(chǔ)設(shè)施)那么對于業(yè)務(wù)相關(guān)的服務(wù)來說，我們有什么線索可以進行垂直劃分嗎？對于應(yīng)用層的服務(wù)來說，我們可以主要以使用該應(yīng)用的業(yè)務(wù)主體來劃分。比如在餐飲系統(tǒng)中，我們可系統(tǒng)管理員、第三方API調(diào)用者，在應(yīng)用和服務(wù)分離103那么領(lǐng)域?qū)幽?？領(lǐng)域?qū)拥奈⒎?wù)之間大部分情況下是平等的。由于領(lǐng)域服務(wù)和系統(tǒng)狀態(tài)（有自己的數(shù)據(jù)庫）相關(guān)性比較強，這些狀態(tài)可以通過模型（實體）來表達。這也是為什么我們通常說的微服務(wù)劃分，實際上是說的領(lǐng)域微服務(wù)，它們的劃分和上下文劃分可以一一對應(yīng)。所以領(lǐng)域服務(wù)的劃分，是根據(jù)系統(tǒng)所處理的客體來劃分的（這是為什么我們劃分領(lǐng)域服務(wù)需要先找模型，因為模型一般是作為這里總結(jié)下應(yīng)用層和領(lǐng)域?qū)觿澐志€索的區(qū)別，以及辨析權(quán)參考業(yè)務(wù)主體為線索來訪問領(lǐng)域?qū)?、基礎(chǔ)設(shè)施層的服務(wù)能力，無權(quán)修改系統(tǒng)的104參考業(yè)務(wù)客體（領(lǐng)域模型）的分類修改系統(tǒng)狀態(tài)當權(quán)責關(guān)系被定義清楚后，開發(fā)團隊在開發(fā)時能減少溝通的成本，但是并不意味著應(yīng)用層和領(lǐng)域?qū)拥镍櫆?。對于?guī)模非常大的系統(tǒng)來說，讓領(lǐng)域?qū)映钟兴械南到y(tǒng)狀態(tài)會變把團隊看作分布式系統(tǒng)團隊管理是一件非常困難的事情，尤其是在認知能力強的群體中尤其如此（和直覺相悖，認知能力越強的團隊越不好管理）。歷史告訴我們，缺乏組織的人類群體沒有任何在一些公司中，管理問題時時刻刻存在，要么靠管理者的本能管理，要么就是管理混亂，或者是靠經(jīng)驗性的管理框其實是可以的，作為一個分布式系統(tǒng)的愛好者，慢慢發(fā)現(xiàn)分布式系統(tǒng)和團隊管理有一些共通之處，能用這些發(fā)現(xiàn)解團隊管理是社會學(xué)討論的問題，分布式系統(tǒng)是計算機中的概念。它們能有什么關(guān)系呢？在開始寫作前，我在和同事這兩個概念甚至都不在一個學(xué)科，一個是文科，而一個算工科的內(nèi)容。但是，世界是非常有意思的，跨學(xué)科的碰撞在《分布式計算――原理、算法與系統(tǒng)》1這本書的開篇這些實體相互協(xié)作可以解決任何單獨的實體所不能解決的問題”。作者認為，分布式系統(tǒng)在宇宙之初就存在了，從蜂群、微生物系統(tǒng)、甚至由人體細胞構(gòu)成的各種系統(tǒng)，這/subject/10785422團隊是一個能獨立承擔一定功能和職責的人類群體，那么也應(yīng)該是一個分布式系統(tǒng)，符合分布式系統(tǒng)的一些基本理接下來我們會聊到分布式系統(tǒng)的兩種模型，分別代表兩種2.反饋調(diào)節(jié)（市場）模型。在宏觀狀態(tài)下適用，當團隊規(guī)模大到不可能被直接管理的時候，只能通過宏大部分情況下，我們不會用到反饋調(diào)節(jié)模型，但是當我們仔細觀察和分析大型企業(yè)的工作機制時，就能發(fā)現(xiàn)端倪。分配分配分配分配讓我們先看下主從調(diào)度模型的基本形態(tài)是什么樣的，它能指導(dǎo)我們加深對團隊的認識嗎？這種系統(tǒng)由兩個主要的角色構(gòu)成：Dispatcher和Worker，這是主從調(diào)度模型的基任務(wù)流回顧一下計算機系統(tǒng)中的這兩個角色。基于負載均衡的無狀態(tài)服務(wù)集群，負載均衡器充當了Dispatcher的角色，普通的服務(wù)器充當了Worker的角色；基于主從的系統(tǒng)Jenkins，它的Master節(jié)點就是Dispatcher角色，在這種模型下，我們發(fā)現(xiàn)如果Master節(jié)點用來跑具體的任務(wù)，會擠壓它的調(diào)度能力，Master節(jié)點崩潰整個系統(tǒng)WorkerLeaderWorkerWorkerWorkerLeaderWorkerWorker我們回歸到團隊管理中來，一名團隊的Leader如果每天關(guān)注在自己具體的工作上，讓W(xué)orker角色的工作擠占了Dispatcher角色的工作，整個團隊會開始混亂。在好的情況下，團隊中會有其他成員自發(fā)地彌補這部分工作，就有點類似于人體被切除某些器官后發(fā)生的代償行為。然而，團隊并不總是有這么好的運氣，如果沒有人來承擔Dispatcher的工作時，整個系統(tǒng)就陷入混亂。所以我們需要將模型做一些簡單的修正，一名Leader不僅需要作為Dispatcher的角色還需要作為Worker完成某些具體的任務(wù)。這也更反映現(xiàn)實，一名技術(shù)經(jīng)理不僅需承擔一定的Worker職責是有好處的，如果不熟悉具體的工作是什么，很難真正地承擔Dispatcher的職責，分解Dispatcher圖2Leader的職能在基本模型中，也可以找到Dispatcher和Worker的主對于Dispatche