Thoughtworks-軟件行業(yè)：換個(gè)角度認(rèn)識(shí)軟件

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