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

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

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

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

亮點：

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

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

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

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

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

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

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

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

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

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

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

書很厚，所以很多具體工具可以跳過，嘗試幾個即可，將來使用的時候知道這本書里有就行了。

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

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

亮點：

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

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

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

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

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

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

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

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

亮點：

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

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

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

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

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

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

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

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

亮點：

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

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

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

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

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

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

......

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

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

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

亮點：

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

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

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

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

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

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

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

亮點：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

......

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

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

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

亮點：

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

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

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

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

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

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

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

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

查看原文，來自MageekChiu。