摘要：持續(xù)交付持續(xù)交付豆瓣微服務(wù)離不開，而核心就是幾點(diǎn)自動(dòng)化連續(xù)小范圍快速可靠。敏捷革命敏捷革命提升個(gè)人創(chuàng)造力與企業(yè)效率的全新協(xié)作模式豆瓣實(shí)際上正是敏捷開發(fā)的最佳實(shí)踐，有了前面的鋪墊，我們可以通過這本書我們來(lái)真正了解敏捷開發(fā)的全貌。

后端好書閱讀與推薦系列文章：
后端好書閱讀與推薦
后端好書閱讀與推薦（續(xù)）
后端好書閱讀與推薦（續(xù)二）
后端好書閱讀與推薦（續(xù)三）
后端好書閱讀與推薦（續(xù)四）
后端好書閱讀與推薦（續(xù)五）
后端好書閱讀與推薦（續(xù)六）
后端好書閱讀與推薦（續(xù)七）

Spring微服務(wù)實(shí)戰(zhàn) (豆瓣): https://book.douban.com/subje...

Spring體系用來(lái)做微服務(wù)在當(dāng)下可謂是風(fēng)頭正勁，這本書就用一個(gè)實(shí)例來(lái)手把手教我們實(shí)現(xiàn)微服務(wù)。實(shí)戰(zhàn)系列的口碑一直不錯(cuò)，這本也不例外，看完就可以對(duì)微服務(wù)的概念有一個(gè)完整的理解，并且想上手也有路可尋。

亮點(diǎn)：

編碼就像藝術(shù)，是一種創(chuàng)造性活動(dòng)。構(gòu)建分布式應(yīng)用就像指揮一個(gè)管弦樂隊(duì)演奏音樂，是一件令人驚奇的事情

微服務(wù)是一個(gè)小的、松耦合的分布式服務(wù)，分解和分離大型復(fù)雜應(yīng)用程序的功能，使它們獨(dú)立，這樣負(fù)責(zé)每個(gè)功能的團(tuán)隊(duì)都擁有自己的代碼庫(kù)和基礎(chǔ)設(shè)施，技術(shù)不限，能靈活地獨(dú)立開發(fā)部署，職責(zé)分離，降低團(tuán)隊(duì)協(xié)作成本。隨著云的普及，微服務(wù)單元的增減（每個(gè)服務(wù)單元都是完整的）變得非常容易，使得整個(gè)應(yīng)用更具彈性伸縮能力。Spring勇于自我革新，當(dāng)初出場(chǎng)取代了沉重的J2EE，后面的Spring Boot使用簡(jiǎn)單注解去掉了自己原本繁重的配置，后來(lái)的Spring Cloud更是為分布式服務(wù)提供了一套完整的解決方案，所以Spring體系是我們構(gòu)建微服務(wù)的絕佳選擇

微服務(wù)構(gòu)建的一個(gè)關(guān)鍵是劃分，而劃分的一個(gè)關(guān)鍵是粒度，這個(gè)沒有絕對(duì)標(biāo)準(zhǔn)，但是有幾個(gè)原則：開始可以讓服務(wù)設(shè)計(jì)范圍大一些，后續(xù)可以重構(gòu)至更小的服務(wù)；重點(diǎn)關(guān)注服務(wù)之間如何交互；隨著對(duì)問題域的理解變化，服務(wù)的職責(zé)也要變化（演化思維）。需要注意微服務(wù)的幾個(gè)壞味道（太粗；太細(xì)）：職責(zé)過多，跨表超過5個(gè)，URL太長(zhǎng)，測(cè)試用例太多；數(shù)量巨大、彼此依賴嚴(yán)重、成為簡(jiǎn)單的curd、只在一個(gè)表操作等

微服務(wù)沒有標(biāo)準(zhǔn)，但是作者提出了12種最佳實(shí)踐：獨(dú)立代碼庫(kù)、顯式依賴、配置存儲(chǔ)、后端可切換、構(gòu)建發(fā)布運(yùn)行必須完整、進(jìn)程無(wú)狀態(tài)、端口命令行制定、橫向擴(kuò)展并發(fā)、可down可up、環(huán)境一致、日志流式處理、管理腳本化。微服務(wù)的生命周期：裝配、引導(dǎo)、發(fā)現(xiàn)、服務(wù)和監(jiān)控、關(guān)閉

少量程序可以使用低層級(jí)文件（YAML、json、XML）來(lái)存儲(chǔ)配置，將其與代碼分開，但是到了數(shù)百單元（每個(gè)單元可能有多個(gè)實(shí)例）時(shí)就不行了。手動(dòng)管理既慢又復(fù)雜還可能配置漂移，這時(shí)應(yīng)該引入配置管理工具（etcd、eureka、consul、zookeeper、spring cloud config等），服務(wù)啟動(dòng)時(shí)通過環(huán)境變量注入配置或者從集中式存儲(chǔ)中獲取

服務(wù)發(fā)現(xiàn)提供了快速水平伸縮的能力，且當(dāng)服務(wù)不健康時(shí)可以快速刪除，還能取代傳統(tǒng)的手動(dòng)管理負(fù)載均衡。主要涉及服務(wù)注冊(cè)、客戶端服務(wù)地址查找、信息共享、健康監(jiān)測(cè)4個(gè)方面

一般大家關(guān)注高可用都是某個(gè)組件徹底不可用（容易檢測(cè)）的情況，但是一個(gè)性能不佳而沒有完全垮掉（不易檢測(cè)）的服務(wù)也可以徹底拖垮整個(gè)應(yīng)用，因此也需要保護(hù)這些不佳服務(wù)，避免連鎖效應(yīng)，導(dǎo)致徹底不可用。一般有客戶端負(fù)載均衡（Ribbon）、斷路器、后備、艙壁（Hystrix）等四個(gè)彈性模式來(lái)實(shí)現(xiàn)保護(hù)緩沖區(qū)

AOP的思想幫我們分離關(guān)注點(diǎn)，那么要在微服務(wù)中實(shí)現(xiàn)靠啥？答案就是網(wǎng)關(guān)（比如Zuul，核心就是反向代理）了，我們可以在網(wǎng)關(guān)中實(shí)現(xiàn)驗(yàn)證授權(quán)、數(shù)據(jù)搜集與日志等關(guān)注點(diǎn)，但是要注意，避免網(wǎng)關(guān)成為單點(diǎn)要注意使其輕量且無(wú)狀態(tài)（無(wú)狀態(tài)就可以很容易擴(kuò)展，而服務(wù)發(fā)現(xiàn)必須有狀態(tài)，所以要擴(kuò)展還要用Gossip等協(xié)議來(lái)同步狀態(tài)數(shù)據(jù)，保障一致性和可用性）

安全注意事項(xiàng)：都要使用HTTPSSSL、所有服務(wù)都要經(jīng)過網(wǎng)關(guān)、將服務(wù)劃分為公共API和私有API、封鎖不必要的端口來(lái)限制微服務(wù)的攻擊面

微服務(wù)不是單體，其好處是靈活，代價(jià)就是解決問題時(shí)難以定位，所以需要追蹤并聚合日志，最終定位問題。spring cloud 給每一個(gè)事務(wù)開啟之前注入關(guān)聯(lián)ID（一般由網(wǎng)關(guān)完成），每個(gè)服務(wù)都可以傳播關(guān)聯(lián)ID并將其添加進(jìn)日志中，這些日志被統(tǒng)一發(fā)送到日志聚合點(diǎn)中，就可以供我們統(tǒng)一檢索了，常見實(shí)現(xiàn)有ELK、Splunk等。光能檢索還不夠，一張直觀的事務(wù)流圖抵過1萬(wàn)條日志，Sleuth和ZipKin一起可以實(shí)現(xiàn)該功能

微服務(wù)強(qiáng)調(diào)靈活迅速，所以一個(gè)成熟的構(gòu)建與部署管道（引入CI/CD）必不可少：提交代碼、自動(dòng)構(gòu)建（鉤子實(shí)現(xiàn)）、構(gòu)建期間進(jìn)行單元測(cè)試與集成測(cè)試后獲得一個(gè)jar（自包含tomcat）、用jar構(gòu)建并提交機(jī)器鏡像、在新環(huán)境中拉取機(jī)器鏡像并進(jìn)行平臺(tái)測(cè)試后啟動(dòng)鏡像、每個(gè)新環(huán)境都要重復(fù)前面一個(gè)步驟

書很厚，所以很多具體工具可以跳過，嘗試幾個(gè)即可，將來(lái)使用的時(shí)候知道這本書里有就行了。

持續(xù)交付 (豆瓣): https://book.douban.com/subje...

微服務(wù)離不開CI/CD，而CI/CD核心就是幾點(diǎn)：自動(dòng)化、連續(xù)、小范圍、快速、可靠。我們通過這本書來(lái)了解CI/CD，也看看持續(xù)交付是如何解決“Last Mile”問題，讓軟件交付不再令人緊張，成為一件簡(jiǎn)單平常的事情。

亮點(diǎn)：

從決定修改到結(jié)果上線的時(shí)間為周期時(shí)間，CI/CD技術(shù)能讓周期從傳統(tǒng)手段的周月單位變成小時(shí)甚至分鐘級(jí)別（產(chǎn)品快速落地，降低機(jī)會(huì)成本），發(fā)布過程可靠可重復(fù)（減少錯(cuò)誤與人力資源），核心技術(shù)就是部署流水線（一個(gè)應(yīng)用從構(gòu)建、部署、測(cè)試到發(fā)布這整個(gè)過程的自動(dòng)化實(shí)現(xiàn)，過程中需要的所有東西包括需求、源碼、配置、腳本、文檔、運(yùn)行環(huán)境等都要納入VCS的管理，但是結(jié)果性的東西比如二進(jìn)制鏡像就不用，因?yàn)樗梢噪S時(shí)構(gòu)建得到，作者羅列了一些相應(yīng)的工具）

提出了一些反模式，讓我們避免：手工部署軟件（復(fù)雜 不可重復(fù)和審計(jì) 易出錯(cuò)）、開發(fā)完成之后才向類生產(chǎn)環(huán)境部署（不確定性很大 發(fā)布有風(fēng)險(xiǎn)）、生產(chǎn)環(huán)境手工配置管理（不能完全掌握 不可重復(fù)）。同時(shí)也提出了一些應(yīng)該遵循的正面原則

持續(xù)集成的前提是版本控制、自動(dòng)化構(gòu)建、團(tuán)隊(duì)共識(shí)，需要做到頻繁提交、自動(dòng)化測(cè)試、保持構(gòu)建和測(cè)試過程較短、管理開發(fā)工作區(qū)、構(gòu)建失敗之后修復(fù)成功之前不能提交新代碼、提交之前自己運(yùn)行測(cè)試、提交測(cè)試通過之后再繼續(xù)工作、時(shí)刻準(zhǔn)備回滾（回滾之前要有一個(gè)修復(fù)時(shí)間）、為自己的問題負(fù)責(zé)、測(cè)試驅(qū)動(dòng)等等

持續(xù)集成能提高團(tuán)隊(duì)對(duì)復(fù)雜系統(tǒng)的自信心與控制力，其主要關(guān)注是開發(fā)團(tuán)隊(duì)，并不能解決軟件部署、交付過程的低效，所以需要一個(gè)端到端的自動(dòng)化構(gòu)建、部署、測(cè)試和發(fā)布流程，也就是部署流水線（關(guān)注的是軟件從CVS到用戶手中這個(gè)過程），它有一些相關(guān)實(shí)踐：只生成一次二進(jìn)制包、不同環(huán)境統(tǒng)一部署、對(duì)部署進(jìn)行冒煙測(cè)試、向生產(chǎn)環(huán)境的副本部署、每次變更都要立即在流水線中傳遞、只要有環(huán)節(jié)失敗停止整個(gè)流水線。CI/CD的關(guān)鍵都是記錄變更，為盡早發(fā)現(xiàn)問題提供信息，消除低效環(huán)節(jié)

部署流水線的幾個(gè)要點(diǎn)：構(gòu)建與部署腳本化（配置初始化數(shù)據(jù)、基礎(chǔ)設(shè)施、中間件等）、提交階段快速反饋與及時(shí)修復(fù)、自動(dòng)化驗(yàn)收測(cè)試（驗(yàn)收測(cè)試是驗(yàn)證客戶的期待，單元測(cè)試是驗(yàn)證開發(fā)人員的期待）、注意非功能測(cè)試（主要指性能）、部署與發(fā)布要有策略并且可重復(fù)執(zhí)行（文本化）且可回滾（不同版本文件不刪除，用符號(hào)鏈接到當(dāng)前版本）

作者說無(wú)論項(xiàng)目大小都應(yīng)使用CI/CD，這個(gè)我感覺有點(diǎn)偏激了，所謂磨刀不誤砍柴工，前提是這個(gè)柴要么很多，要么很大，如果只是幾根細(xì)柴，有那個(gè)磨刀的功夫柴都砍完了。但是實(shí)際工作中這么小的項(xiàng)目應(yīng)該很少，所以大多數(shù)項(xiàng)目我們還是都還是應(yīng)該搭建部署流水線，用上CI/CD。
書很厚，其實(shí)好多地方可以跳過，你只需要看標(biāo)題就能抓住主旨而無(wú)需多看。
PS：可以先看看這本持續(xù)集成。

敏捷革命：提升個(gè)人創(chuàng)造力與企業(yè)效率的全新協(xié)作模式 (豆瓣): https://book.douban.com/subje...

CI/CD 實(shí)際上正是敏捷開發(fā)的最佳實(shí)踐，有了前面的鋪墊，我們可以通過這本書我們來(lái)真正了解敏捷開發(fā)的全貌。

亮點(diǎn)：

2005年之前，大多數(shù)軟件開發(fā)項(xiàng)目都是采用“瀑布法”：整個(gè)項(xiàng)目被劃分為多個(gè)階段，每個(gè)階段都要經(jīng)過嚴(yán)格的評(píng)審，以期為客戶或軟件使用者提供完美的產(chǎn)品（甘特圖表現(xiàn)），每一階段的工作做得足夠好時(shí)才允許進(jìn)入下一階段。這種工作方式看似完美，實(shí)際全憑想象和猜測(cè)、華而不實(shí)，往往導(dǎo)致開發(fā)進(jìn)度緩慢，常常超出預(yù)算，且現(xiàn)實(shí)和規(guī)劃差異巨大，Scrum（敏捷開發(fā)流程）的出現(xiàn)就是解決這個(gè)問題的（不憑猜測(cè)，而是PDCA：計(jì)劃、執(zhí)行、檢查、行動(dòng)）

任何項(xiàng)目的管理都需要實(shí)現(xiàn)兩個(gè)目標(biāo)：可控性與可預(yù)測(cè)性

管理層的職責(zé)在于制定戰(zhàn)略目標(biāo)，團(tuán)隊(duì)的工作則是決定如何完成目標(biāo)。無(wú)論任何人，只要不在現(xiàn)場(chǎng)，都不可能及時(shí)跟上事態(tài)變化的步調(diào)，所以團(tuán)隊(duì)要有自主決策權(quán)，此外一個(gè)團(tuán)隊(duì)需要包含完成一個(gè)項(xiàng)目的所有技能，同時(shí)要小而精（7人左右）。團(tuán)隊(duì)成員之間不要互相指責(zé)，而是盡量改善制度

“沖刺”（一般以星期為周期）可以讓團(tuán)隊(duì)成員集中精力快速做出成果并得到反饋，“每日立會(huì)”（15分鐘以內(nèi)）能讓成員清楚地知道沖刺進(jìn)度如何。Scrum的核心就是節(jié)奏

確定懂項(xiàng)目、懂市場(chǎng)、懂顧客的產(chǎn)品負(fù)責(zé)人，擬定待辦事項(xiàng)清單并檢測(cè)兩遍，重要的事情優(yōu)先做

這本書細(xì)看的話真的很洗腦，看完感覺自己迫不及待地想要沖進(jìn)一家公司試試Scrum了。

DevOps實(shí)踐指南 (豆瓣): https://book.douban.com/subje...

DevOps是軟件開發(fā)、運(yùn)維和質(zhì)量保證三個(gè)部門之間的溝通、協(xié)作和集成所采用的流程、方法和體系的一個(gè)集合（所以也要基于CI/CD，前4本書可以看做一個(gè)連續(xù)的專題，核心都是敏捷）。它取代了傳統(tǒng)開發(fā)、測(cè)試、運(yùn)維職責(zé)大分離的思想，填平了部門之間的鴻溝，讓大家更有效的工作。我們可以通過這本書來(lái)對(duì)DevOps有一個(gè)全面的了解。

亮點(diǎn)：

開發(fā)部通常負(fù)責(zé)對(duì)市場(chǎng)變化做出響應(yīng)，以最快的速度將新功能或者變更上線。而運(yùn)維部則要以提供穩(wěn)定、可靠和安全的服務(wù)為已任，讓任何人都很難甚至無(wú)法引入可能會(huì)危害生產(chǎn)環(huán)境的變更。這種配置方式讓開發(fā)部門和IT運(yùn)維部門的目標(biāo)和動(dòng)因之間存在“根本的、長(zhǎng)期的沖突”——公司對(duì)不同部門的考核和激勵(lì)不同，這種沖突造成了一種惡性循環(huán)，阻礙了公司全局目標(biāo)的實(shí)現(xiàn)。DevOps能夠提高公司業(yè)績(jī)，實(shí)現(xiàn)開發(fā)、QA、IT運(yùn)維、信息安全等各職能技術(shù)角色的目標(biāo)，同時(shí)改善人們的境遇

DevOps是精益、約束理論、豐田生產(chǎn)系統(tǒng)、柔性工程、學(xué)習(xí)型組織、康威定律等知識(shí)體系的集大成者

DevOps“三步工作法”：流動(dòng)、反饋、持續(xù)學(xué)習(xí)與實(shí)驗(yàn)，并闡述了DevOps實(shí)施需遵守的原則與最佳實(shí)踐（流動(dòng)：它加速了從開發(fā)、運(yùn)維到交付給客戶的正向流程；反饋：它使組織構(gòu)建安全可靠的工作體系，并獲得反饋；持續(xù)學(xué)習(xí)與實(shí)驗(yàn)：它打造出一種高度信任的文化，并將改進(jìn)和創(chuàng)新融入日常工作中）

為了能識(shí)別工作在哪里流動(dòng)、排隊(duì)或停滯，需要將工作盡可能地可視化，如在看板或Sprint計(jì)劃板上，使用紙質(zhì)或電子卡片將各項(xiàng)工作展示出來(lái),通過這種方式，不僅能將工作內(nèi)容可視化，還能有效地管理工作，加速其從左至右的流動(dòng),還可以通過卡片從在看板上創(chuàng)建到移動(dòng)至“完成”這一列，度量出工作的前置時(shí)間。此外，看板還能控制在制品數(shù)量（隊(duì)列長(zhǎng)度）

文中關(guān)于小批量和大批量的差異，我以前在博客中也提到過。如此看來(lái)，兩種方式各有優(yōu)劣，關(guān)鍵看能分配的資源是什么？更追求總體效率還是效果出現(xiàn)的等待時(shí)間？對(duì)返工的要求是什么？再來(lái)決定使用方法

第一步描述的原則，使得工作能夠在價(jià)值流中從左向右快速地流動(dòng)。第二步描述的原則，使得在從右向左的每個(gè)階段中能夠快速、持續(xù)地獲得工作反饋。快速發(fā)現(xiàn)問題、群策群力解決問題，可以避免把問題帶入下游環(huán)節(jié)，避免修復(fù)成本指數(shù)增加。根據(jù)精益原則，我們最重要的客戶是我們的下游（不一定是最終付費(fèi)用戶），為他們而優(yōu)化我們的工作，在源頭保障質(zhì)量。第三步描述的原則可以持續(xù)提升個(gè)人技能，進(jìn)而轉(zhuǎn)化為團(tuán)隊(duì)的財(cái)富

......

感覺歷史的天平總是左右搖擺，一開始職責(zé)混亂、一個(gè)人干所有的事，后來(lái)職責(zé)分離、分工明確，現(xiàn)在又提倡填平鴻溝、部門融合。隨著時(shí)代的發(fā)展，適用于時(shí)代的技術(shù)也總是不停變更，要想不被淘汰就得終身學(xué)習(xí)呀。

Web容量規(guī)劃的藝術(shù) (豆瓣): https://book.douban.com/subje...

容量規(guī)劃（很早就有了，如道路規(guī)劃、電力運(yùn)營(yíng)）是一門省錢的藝術(shù)，保證用合理的資源來(lái)實(shí)現(xiàn)最大化需求，通過這本書我們來(lái)敲開容量規(guī)劃在互聯(lián)網(wǎng)世界中實(shí)際運(yùn)用的大門。

亮點(diǎn)：

容量規(guī)劃整個(gè)過程：首先要明確定義響應(yīng)時(shí)間、可供消耗容量以及峰值驅(qū)動(dòng)處理等明確指標(biāo)來(lái)定義總體負(fù)載和容量需求，然后了解當(dāng)前基礎(chǔ)設(shè)施的負(fù)荷特征，預(yù)測(cè)需要的資源來(lái)達(dá)到這種性能，然后如何管理資源，最后不斷迭代，最終目標(biāo)介于“沒有買足夠資源”和“浪費(fèi)太多資源”之間

有幾個(gè)方法：預(yù)測(cè)系統(tǒng)何時(shí)失敗、用統(tǒng)計(jì)圖表（比數(shù)字更直觀）呈現(xiàn)問題、性能調(diào)優(yōu)與容量規(guī)劃要同步進(jìn)行、搜集數(shù)據(jù)驅(qū)動(dòng)未來(lái)的規(guī)劃

測(cè)量是規(guī)劃的前提，要有堅(jiān)實(shí)的數(shù)據(jù)支撐而不是猜測(cè)，有許多工具可以測(cè)量，他們應(yīng)該可以隨著時(shí)間記錄和保存數(shù)據(jù)、自定義度量、比較指標(biāo)、導(dǎo)入和導(dǎo)出指標(biāo)，當(dāng)然測(cè)量工具本身要輕量，盡量對(duì)資源本身影響較小。

如果說測(cè)量是對(duì)已有情況的了解，那么估計(jì)就是根據(jù)數(shù)據(jù)趨勢(shì)預(yù)測(cè)未來(lái)。預(yù)測(cè)部分靠直覺，部分靠數(shù)學(xué)。我們可以做曲線擬合，注意到趨勢(shì)和變更，并進(jìn)行迭代和校準(zhǔn)（看來(lái)基于機(jī)器學(xué)習(xí)或者說AI的運(yùn)維是未來(lái)?。?/p>

文章除了基于傳統(tǒng)模式的容量規(guī)劃，還涉及到了基于虛擬化和云計(jì)算的模式，所以我們學(xué)習(xí)也要注意趨勢(shì)和變化。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì) (豆瓣): https://book.douban.com/subje...

構(gòu)建程序之前，我們都要對(duì)業(yè)務(wù)進(jìn)行梳理和理解，然后是領(lǐng)域劃分與建模等一系列重要步驟，最后才是編碼實(shí)現(xiàn)，這就是一本講解這些步驟的好書。而且本書會(huì)告訴你，設(shè)計(jì)和實(shí)現(xiàn)可以交錯(cuò)進(jìn)行和演化，來(lái)達(dá)到最優(yōu)。還提出了專業(yè)術(shù)語(yǔ)，你在和別人交流時(shí)可以使用。
我在讀到假同源這個(gè)詞語(yǔ)時(shí)真是猶如醍醐灌頂，因?yàn)橹伴_發(fā)項(xiàng)目就有過：同一個(gè)對(duì)象，這個(gè)模塊改吧改吧，那個(gè)模塊改吧改吧，最后導(dǎo)致對(duì)兩個(gè)模塊而言，這個(gè)對(duì)象都不完全屬于它，要修改都得小心翼翼怕影響對(duì)方，本書告訴我，遇上假同源，要么重新理解和建模，統(tǒng)一該對(duì)象表示，要么果斷分開這兩個(gè)模塊，用兩個(gè)對(duì)象分別服務(wù)這兩個(gè)模塊。

亮點(diǎn)：

模型是一種簡(jiǎn)化，是對(duì)現(xiàn)實(shí)的解釋，把與解決問題密切相關(guān)的方面抽象出來(lái)，而忽略無(wú)關(guān)的細(xì)節(jié)（所以需要我們消化和提煉已有知識(shí)，包括深層次探索）。用戶應(yīng)用軟件的問題區(qū)域就是軟件的領(lǐng)域（有形的如機(jī)票系統(tǒng)，無(wú)形的如會(huì)計(jì)系統(tǒng)）。成功的項(xiàng)目有一個(gè)共同特征：都有一個(gè)豐富的領(lǐng)域模型，這個(gè)模型在迭代設(shè)計(jì)過程中不斷演變（我們要持續(xù)學(xué)習(xí)），與實(shí)現(xiàn)綁定，成為項(xiàng)目不可分割的一部分

很多因素可能會(huì)導(dǎo)致項(xiàng)目偏離軌道，但真正決定軟件復(fù)雜性的是設(shè)計(jì)方法。當(dāng)復(fù)雜性失去控制時(shí)，開發(fā)人員就無(wú)法很好地理解軟件，因此無(wú)法輕易、安全地更改和擴(kuò)展它，而好的設(shè)計(jì)則可以為開發(fā)復(fù)雜特性創(chuàng)造更多機(jī)會(huì)。一些設(shè)計(jì)因素是技術(shù)上的，很多技術(shù)人員都能輕易注意到并改進(jìn)，但是很多程序主要的復(fù)雜性并不在技術(shù)上，而是來(lái)自領(lǐng)域本身、用戶的活動(dòng)或業(yè)務(wù)，這部分往往被許多人忽略

要避免不設(shè)計(jì)和過度設(shè)計(jì)（極限編程）

模型、設(shè)計(jì)的核心、實(shí)現(xiàn)互相影響和關(guān)聯(lián)；模型是團(tuán)隊(duì)所有人員溝通的中樞，使得開發(fā)人員和領(lǐng)域?qū)＜覠o(wú)需翻譯就能溝通，高效簡(jiǎn)潔；模型是濃縮的知識(shí)

技術(shù)人才更愿意從事精細(xì)的框架工作，試圖用技術(shù)來(lái)解決領(lǐng)域問題，把學(xué)習(xí)領(lǐng)域知識(shí)和領(lǐng)域建模的工作留給別人去做。軟件核心的復(fù)雜性需要我們直接去面對(duì)和解決，如果不這樣做，則可能導(dǎo)致工作重點(diǎn)的偏離——軟件的初衷以及核心就是為了解決領(lǐng)域問題

對(duì)于比較重要的業(yè)務(wù)規(guī)則（這個(gè)知識(shí)點(diǎn)需要我們自己去理解）比如貨船超訂110%，應(yīng)該多帶帶抽象成1個(gè)實(shí)體（具體就可以是1個(gè)方法），而不是簡(jiǎn)單的用一個(gè)guard clause來(lái)實(shí)現(xiàn)，這樣既能明確這個(gè)知識(shí)點(diǎn)本身，又利于代碼的擴(kuò)展性。當(dāng)然，把不重要的細(xì)節(jié)也多帶帶抽象就是典型的過度設(shè)計(jì)了

以文本為主，簡(jiǎn)潔的小圖為輔（大而全的圖反而失去了解釋能力）來(lái)闡釋模型最好。文檔是代碼和口頭交流的補(bǔ)充，為團(tuán)隊(duì)提供穩(wěn)定和共享的交流。只用代碼做文檔容易使人陷入細(xì)節(jié)，不能把控全局，所以應(yīng)該文檔和代碼互補(bǔ)，文檔不再重復(fù)闡述代碼能表現(xiàn)的內(nèi)容而是著重核心元素，闡明設(shè)計(jì)意圖，文檔還要注意和代碼保持同步不脫節(jié)（不再適用的文檔要進(jìn)行歷史歸檔），不然就失去了意義。模型與實(shí)現(xiàn)也要同步，通過模型驅(qū)動(dòng)設(shè)計(jì)MDD實(shí)現(xiàn)，保證模型既利于實(shí)現(xiàn)，也利于前期的分析

要想創(chuàng)建出能處理復(fù)雜任務(wù)的程序，需要做到關(guān)注點(diǎn)分離，使設(shè)計(jì)中的每個(gè)部分都得到多帶帶的關(guān)注，行業(yè)普遍采用分層架構(gòu)，分層的價(jià)值在于每一層都只代表程序中的某一特定方面，每個(gè)方面的設(shè)計(jì)都更具內(nèi)聚性，更容易解釋。分層設(shè)計(jì)大都是“用戶層界面-應(yīng)用層-領(lǐng)域?qū)?基礎(chǔ)設(shè)施層”這種四層架構(gòu)的變體，其中領(lǐng)域?qū)邮擒浖暮诵?，將其分離才是MDD的關(guān)鍵，也是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD的前提。領(lǐng)域?qū)优c應(yīng)用層的區(qū)分關(guān)鍵在于領(lǐng)域?qū)影瑢?shí)際業(yè)務(wù)規(guī)則（如轉(zhuǎn)賬操作），而應(yīng)用層是為了實(shí)現(xiàn)業(yè)務(wù)的輔助功能（如導(dǎo)入轉(zhuǎn)賬文本記錄）

DDD適用于大型項(xiàng)目，小項(xiàng)目用“Smart UI”更合適，還有其他的架構(gòu)模式都有自己的使用場(chǎng)景和局限

領(lǐng)域中用來(lái)表示某種具有連續(xù)性和標(biāo)識(shí)（比如銀行賬戶）的事物是ENTITY，用于描述某種狀態(tài)的屬性是VALUE OBJECT（不可變，無(wú)標(biāo)識(shí)，比如數(shù)字3，盡量設(shè)計(jì)為不可變，便于復(fù)制和共享），動(dòng)作或操作最好用SERVICE來(lái)表示（在大型系統(tǒng)中，中等粒度、無(wú)狀態(tài)的SERVICE更容易被復(fù)用），對(duì)象之間的關(guān)聯(lián)可以通過限定條件進(jìn)行簡(jiǎn)化，MODULE是一種更粗粒度的建模和設(shè)計(jì)單元（提供了兩種觀察模型的方式，一是可以在MODULE中查看細(xì)節(jié)，而不會(huì)被整個(gè)模型淹沒，二是觀察MODULE之間的關(guān)系，而不考慮其內(nèi)部細(xì)節(jié)）。領(lǐng)域模型中的每個(gè)概念都應(yīng)該在實(shí)現(xiàn)元素中反映出來(lái)

由于汽車的裝配和駕駛永遠(yuǎn)不會(huì)同時(shí)發(fā)生，因此將這兩種功能合并到同一個(gè)機(jī)制中是毫無(wú)價(jià)值的。同理，裝配復(fù)雜的復(fù)合對(duì)象的工作也最好與對(duì)象要執(zhí)行的工作分開。應(yīng)該將創(chuàng)建復(fù)雜對(duì)象（比如依賴其他對(duì)象B的對(duì)象A就是復(fù)雜對(duì)象，不要直接在A構(gòu)造函數(shù)中調(diào)用B的構(gòu)造函數(shù)）的實(shí)例和AGGREGATE（一組相關(guān)對(duì)象的集合，比如車輛與發(fā)動(dòng)機(jī)）的職責(zé)轉(zhuǎn)移給多帶帶的對(duì)象：FACTORY

初始模型通常都是基于對(duì)領(lǐng)域的淺顯認(rèn)知而構(gòu)建的，不夠成熟也不夠深入，通過重構(gòu)（不僅是一般的代碼細(xì)節(jié)的重構(gòu)，還有領(lǐng)域的重構(gòu)，后者通常風(fēng)險(xiǎn)很高，但是回報(bào)也很高，需要在前者的不斷積累下尋找突破）最終開發(fā)出能夠捕捉到領(lǐng)域深層含義的模型，這也是管理項(xiàng)目的規(guī)模和復(fù)雜性的要素，加上柔性設(shè)計(jì)（軟件易于修改）就能讓項(xiàng)目穩(wěn)步發(fā)展。持續(xù)重構(gòu)漸漸被認(rèn)為是一種“最佳實(shí)踐”，但大部分項(xiàng)目團(tuán)隊(duì)仍然對(duì)它抱有很大的戒心。人們雖然看到了修改代碼會(huì)有風(fēng)險(xiǎn)，還要花費(fèi)開發(fā)時(shí)間，但卻不容易看到維持一個(gè)拙劣設(shè)計(jì)也有風(fēng)險(xiǎn)，而且遷就這種設(shè)計(jì)也要付出代價(jià)

代碼除了要能準(zhǔn)確得到結(jié)果外，還要能顯式的表達(dá)出領(lǐng)域的規(guī)則，易于理解和預(yù)測(cè)修改代碼的影響。所以有一些原則：揭示意圖的接口，能避免用戶去研究它的實(shí)現(xiàn)（失去了封裝的價(jià)值）；無(wú)副作用的函數(shù)，安全地預(yù)見函數(shù)的作用，避免組合爆炸；斷言可以幫助展示和理解副作用

技術(shù)角度的設(shè)計(jì)模式中的一些也適用于領(lǐng)域設(shè)計(jì)，比如Strategy和Composite模式，把設(shè)計(jì)模式用作領(lǐng)域模式的唯一要求是這些模式能夠描述關(guān)于概念領(lǐng)域的一些事情，而不僅是作為解決技術(shù)問題的技術(shù)解決方案

大型系統(tǒng)的模型很復(fù)雜，需要注意三個(gè)要素：上下文（不要強(qiáng)制在大型系統(tǒng)中統(tǒng)一模型，可以在不同的上下文使用不同的模型（注意重復(fù)概念和假同源），劃定好邊界即可）、精煉和大型結(jié)構(gòu)，才能操縱和理解這個(gè)模型

......

DDD我們可能都用過，但是很可能沒把它當(dāng)成一項(xiàng)正經(jīng)學(xué)問，都是大概過一下需求，稍微捋一捋邏輯然后就開始編碼了，實(shí)際上，在我們這個(gè)過程我們已經(jīng)經(jīng)歷了ffffd，看完本書以后希望能把這個(gè)過程正規(guī)化，流程化，高效化。

Go語(yǔ)言實(shí)戰(zhàn) (豆瓣): https://book.douban.com/subje...

上本書給我們講了go的基礎(chǔ)知識(shí)和原理，這本書就帶領(lǐng)我們用go的各種庫(kù)和工具進(jìn)行實(shí)戰(zhàn)。

亮點(diǎn)：

計(jì)算機(jī)一直在演化，但是編程語(yǔ)言并沒有以同樣的速度演化。現(xiàn)在的高性能服務(wù)器擁有 64 核、128 核，甚至更多核。但是我們依舊在使用為單核設(shè)計(jì)的技術(shù)在編程。Go語(yǔ)言對(duì)傳統(tǒng)的面向?qū)ο箝_發(fā)進(jìn)行了重新思考，并且提供了更高效的復(fù)用代碼的手段。Go語(yǔ)言還讓用戶能更高效地利用昂貴服務(wù)器上的所有核心，而且它編譯大型項(xiàng)目的速度也很快

經(jīng)驗(yàn)，如果需要聲明初始為零值的變量，應(yīng)該使用 var 關(guān)鍵字聲明變量；如果提供確切的非零值初始化變量或者使用函數(shù)返回值創(chuàng)建變量，應(yīng)該使用簡(jiǎn)化變量聲明運(yùn)算符 :=

go vet工具不能讓開發(fā)者避免嚴(yán)重的邏輯錯(cuò)誤，或者避免編寫充滿小錯(cuò)的代碼。不過可以很好地捕獲一部分常見錯(cuò)誤。每次對(duì)代碼先執(zhí)行 go vet 再將其簽入源代碼庫(kù)是一個(gè)很好的習(xí)慣；在保存文件或者提交到代碼庫(kù)前執(zhí)行 go fmt可以統(tǒng)一代碼風(fēng)格

go在函數(shù)之間傳遞變量時(shí)，總是以值的方式傳遞的。函數(shù)間傳遞數(shù)組可能涉及大量數(shù)據(jù)拷貝，最好傳遞數(shù)組的指針，就只用拷貝8字節(jié)的指針而非拷貝數(shù)組本身。相反，與切片關(guān)聯(lián)的數(shù)據(jù)包含在底層數(shù)組里，不屬于切片本身，所函數(shù)間直接傳遞切片沒有性能影響，映射也是；在創(chuàng)建切片時(shí)設(shè)置切片的容量和長(zhǎng)度一樣，就可以強(qiáng)制讓新切片的第一個(gè) append 操作創(chuàng)建新的底層數(shù)組，與原有的底層數(shù)組分離，可以安全地進(jìn)行修改而不影響原切片，同時(shí)也保持了為切片申請(qǐng)新的底層數(shù)組的代碼簡(jiǎn)潔性

關(guān)鍵字 func 和函數(shù)名之間的參數(shù)被稱作接收者，將函數(shù)與接收者的類型綁在一起。如果一個(gè)函數(shù)有接收者，這個(gè)函數(shù)就被稱為方法。值接收者使用值的拷貝副本來(lái)調(diào)用方法，而指針接受者使用實(shí)際值來(lái)調(diào)用方法。Go語(yǔ)言會(huì)調(diào)整傳入的參數(shù)，無(wú)論是指針接受者還是值接受者都可以接受指針或者值兩種類型，說是方便開發(fā)，但我覺得這反而是一個(gè)不必要的歧義，比如到了接口的方法集中，如果使用指針接收者來(lái)實(shí)現(xiàn)一個(gè)接口，那么只有指向那個(gè)類型的指針才能夠?qū)崿F(xiàn)對(duì)應(yīng)的接口。如果使用值接收者來(lái)實(shí)現(xiàn)一個(gè)接口，那么那個(gè)類型的值和指針都能夠?qū)崿F(xiàn)對(duì)應(yīng)的接口，主要原因是編譯器并不是總能自動(dòng)獲得一個(gè)值的地址

通過嵌入類型，與內(nèi)部類型相關(guān)的標(biāo)識(shí)符會(huì)提升到外部類型上。這些被提升的標(biāo)識(shí)符就像直接聲明在外部類型里的標(biāo)識(shí)符一樣，也是外部類型的一部分，可以無(wú)縫實(shí)現(xiàn)對(duì)象組合，需要注意嵌入類型不需要聲明字段。如

  type admin struct {            type admin struct {
      user // 嵌入類型                user user//聲明字段，不是嵌入
      level string                   level string
  }                              }

Go語(yǔ)言的并發(fā)同步模型來(lái)自一個(gè)叫作通信順序進(jìn)程（Communicating Sequential Processes，CSP）的范型（ paradigm）。CSP 是一種消息傳遞模型，通過在 goroutine 之間傳遞數(shù)據(jù)來(lái)傳遞消息，而不是對(duì)數(shù)據(jù)進(jìn)行加鎖來(lái)實(shí)現(xiàn)同步訪問。go 的競(jìng)爭(zhēng)檢測(cè)器 go build -race 可以有效檢測(cè)代碼里面的競(jìng)爭(zhēng)狀態(tài)。go可以通過原子函數(shù)、互斥鎖和通道發(fā)送接受共享資源來(lái)實(shí)現(xiàn)同步

查看原文，來(lái)自MageekChiu。