20210329-20210402技術週報

哈嘍哈嘍你們猴，我是把代碼寫成bug的大頭菜。公衆號：大頭菜技術(bigheadit)。原創不易，但歡迎轉載。

這周總得來講，大頭菜比較忙，但也不忘學習。這周主要學習了領域驅動設計DDD。爲何學這個東西，由於最近大頭菜和一位大佬L討論需求設計時，大佬L指出我作接口設計時，太過於從代碼出發，作的東西能夠符合一次需求，可是沒沉澱，沒法解決更多同質問題，

雖然我作的項目是分佈式項目，可是個人思考方式卻停留在單機架構：整個系統圍繞數據庫驅動設計和開發。這其實很顯然就是思惟上的停滯和懶惰。表面上你作的是分佈式項目，但本質設計和開發還停留在單機架構。我相信不僅我一我的是這樣子的，你也能夠反觀一下本身哈哈哈。

面對這困局，我深知本身急需破局。我須要從思惟層面上，從面向數據庫設計和開發，轉變到領域建模實戰。

我本身看的書籍是領域驅動設計。目前看了一些DDD的基本概念。下週能夠繼續看進階篇，若是不忙，應該能夠直接到實戰部分。看吧，下面是我看DDD時，本身整理的一些疑惑和筆記。

DDD筆記

一、DDD的用途？

A:用來指導中臺和微服務的設計

二、中臺，DDD和微服務三者的關係

A:中臺本質是業務模型，微服務是業務模型的系統落地，DDD 是一種設計思想，它能夠同時指導中臺業務建模和微服務設計，它們之間就是這樣的一個鐵三角關係。DDD 強調領域模型和微服務設計的一體性，先有領域模型而後纔有微服務，而不是脫離領域模型來談微服務設計。

三、微服務拆分困難的緣由

綜合來看，我認爲微服務拆分困境產生的根本緣由就是不知道業務或者微服務的邊界到底在什麼地方。換句話說，肯定了業務邊界和應用邊界，這個困境也就迎刃而解了。

DDD就是用來指導微服務拆分的指導思想。

四、DDD是什麼？

DDD 是一種處理高度複雜領域的設計思想，它試圖分離技術實現的複雜性，並圍繞業務概念構建領域模型來控制業務的複雜性，以解決軟件難以理解，難以演進的問題。DDD 不是架構，而是一種架構設計方法論，它經過邊界劃分將複雜業務領域簡單化，幫咱們設計出清晰的領域和應用邊界，能夠很容易地實現架構演進。

五、總結

面對複雜問題，解決辦法一般是拆分，模塊化，化整爲零。領域驅動建模DDD是面向業務，對業務領域的劃分和整合，是邏輯層面。微服務是面向物理落地，是對應用的物理形態進行拆分和整合。從軟件工程過程角度看，DDD的戰略設計輸出物，領域模型及劃分的區域，是微服務的輸入，一個區域對應一個微服務，微服務運行框架、平臺能夠承載全部的微服務，提供微服務統一的運行框架，也就是承載全部的業務領域。可見領域驅動與微服務是在軟件不一樣階段使用的工具，技術或方法論，圍繞一個共同的目標，搭建企業業務中臺，企業級業務複用，快速的需求響應能力。DDD戰略設計得輸出，是微服務的輸入。

六、領域

領域就是範圍。DDD就是不斷強調範圍，強調邊界。

七、子領域

領域進一步劃分就是子領域。咱們把劃分出來的多個子領域稱爲子域，每一個子域對應一個更小的問題域或更小的業務範圍。

八、子域的分類

在領域不斷劃分的過程當中，領域會細分爲不一樣的子域，子域能夠根據自身重要性和功能屬性劃分爲三類子域，它們分別是：核心域、通用域和支撐域。
核心域成功的關鍵，通用域是能夠買的，支撐域是能夠外包的

九、什麼是通用語言

在事件風暴過程當中，經過團隊交流達成共識的，可以簡單、清晰、準確描述業務涵義和規則的語言就是通用語言

十、DDD 分析和設計過程當中的每個環節都須要保證限界上下文內術語的統一，在代碼模型設計的時侯就要創建領域對象和代碼對象的一一映射，從而保證業務模型和代碼模型的一致，實現業務語言與代碼語言的統一。

十一、爲何要提出限界上下文

爲了不一樣的概念或語義在不一樣的上下文環境中產生歧義，DDD 在戰略設計上提出了「限界上下文」這個概念，用來肯定語義所在的領域邊界。

舉個例子：
在一個明媚的早晨，孩子起牀問媽媽：「今天應該穿幾件衣服呀？」媽媽回答：「能穿多少就穿多少！」那究竟是穿多仍是穿少呢？若是沒有具體的語義環境，還真不太好理解。可是，若是你已經知道了這句話的語義環境，好比是寒冬臘月或者是炎炎夏日，那理解這句話的涵義就會很容易了。因此語言離不開它的語義環境。

理論上限界上下文就是微服務的邊界。咱們將限界上下文內的領域模型映射到微服務，就完成了從問題域到軟件的解決方案。

十二、什麼是實體

對這些對象而言，重要的不是其屬性，而是其延續性和標識，對象的延續性和標識會跨越甚至超出軟件的生命週期。咱們把這樣的對象稱爲實體

1三、什麼是值對象

值對象描述了領域中的一件東西，這個東西是不可變的，它將不一樣的相關屬性組合成了一個概念總體

1四、實體和值對象的區別？

實體着重惟一性和延續性，不在乎屬性的變化，屬性全變了，它仍是原來那個它；值對象着重描述性，對屬性的變化很敏感，屬性變了，它就不是那個它了。

生產事故——磁盤使用率爆滿

已經專門寫了一篇文章來描述磁盤使用率爆滿事件，直接進去看就好，這裏就不重複了。

分享一些工做中的趣事

我就瞎聊了。

最近我作了一個修改商家別名的需求。一個商家有多條業務線，好比有送外賣的，有租車的，每一條業務線都容許有不一樣的別名。在這個大背景下，需求就產生了。一開始這個需求很快設計、開發、提測、上線，真是一鼓作氣啊！然而，上線後，發現不少其餘下游系統都有調用這個接口，好比C端的商家列表頁，詳情頁，後臺的列表頁。。。。這個需求一共前先後後，上線了3次，才把坑填好。有人會問，不能保證接口返回值一致嗎？其實，我已經保持一致了。但此次由於容許每一條業務線都有商家別名，須要換表。之前的接口，是從緩存中查詢別名的，如今的接口，已經換表了，直接懟數據庫。由於數據量不大，不必中間加緩存了。

第二件事：我和我後端同事R對接接口，個人返回值，先說明，永遠不可能爲null的。可是呢，我同事R調個人查詢接口，說日誌打印了null值。接受過九年義務教育的我，都是先反思本身，再去懷疑別人。因而乎，我就把個人代碼從頭至尾看了一遍，發現都不可能給他返回null。我也看了一下我這邊的日誌，發現，很是正常呀，都是返回一個JSON值給他。但他那邊的日誌又確確實實是Null值。害！那時候我已經以爲本身瘋了，就在我準備放棄前，我要求看看他的代碼。代碼以下：

List list = null;

XXXService.getList();

log.info(JSON.toJSONStirng(list))

看到這裏，我破口而出：哥，你都沒賦值，沒賦值。我當時都結巴了，由於實在啼笑皆非。好氣又可笑！！！

老司機滑鐵盧了！！！！

今天就聊到這了，簡單地覆盤了一下上週的工做和生活。想問個問題，清明節快到了，大家被人祝福過清明節快樂嗎哈哈哈哈！

福利

公衆號後臺回覆:性能優化 可領取相關JVM性能調優學習資料。