前面先寫一點(diǎn)廢話。
由于最近在整理一些DDD、微服務(wù)、架構(gòu)相關(guān)的知識總結(jié)，一邊看一邊回憶一些經(jīng)歷，又由于本人看的東西有時候很雜，記憶力又大不如前，本打算僅用私人手賬的形式記錄一下。
但回看了一下2019年年前立的flag —— 50篇博客（應(yīng)該是完不成了吧。。），又想到最近一段時間接觸到的咨詢同事的寫作能力，唉。
雖然對自身寫作和語言表述能力有些萎靡不振，但，人不能不上進(jìn)。
因此，準(zhǔn)備開始簡書。

這里有人可能要問了：你不是跑去搞區(qū)塊鏈了嗎，怎么又跑回來微服務(wù)、DDD了？
嗯。。這個問題問的好。這里就不得不提到本人去搞區(qū)塊鏈之前的一段近兩年的項(xiàng)目經(jīng)歷了。
怎么說呢，這個項(xiàng)目雖然在我的項(xiàng)目經(jīng)歷中已經(jīng)完結(jié)了，但它遺留在我心中的問題還沒有完結(jié)。
就是這樣。

有時候你不得不去寫的業(yè)務(wù)代碼

最近出差回來，遇到一些之前項(xiàng)目上的同事聊到自己當(dāng)前的新項(xiàng)目，無不感嘆——不用再像以前一樣不停地寫業(yè)務(wù)代碼了。
嗯，可以多玩一些技術(shù)、或者新的技術(shù)，總是可以讓搞技術(shù)的人興奮很久。
但是，比較可惜，所謂技術(shù)要盈利，就要交付產(chǎn)品。要交付產(chǎn)品，必然就會有業(yè)務(wù)。即使是DevOps平臺這種純技術(shù)型的產(chǎn)品，技術(shù)上的CI/CD就是它的業(yè)務(wù)。
寫業(yè)務(wù)代碼，對每個開發(fā)來說，基本上都必不可少。
這時候，技術(shù)需要通過實(shí)現(xiàn)業(yè)務(wù)，來展現(xiàn)價值。

寫了這么多業(yè)務(wù)代碼，你是否真的會寫業(yè)務(wù)代碼

一定會有人覺得這個問題很奇怪，業(yè)務(wù)代碼不就是一個不斷累加的過程么，有什么會與不會？
說實(shí)話，在沒有之前那次兩年經(jīng)驗(yàn)的時候，我也是這樣想的。但通過那兩年的經(jīng)歷，我意識到 —— 復(fù)雜業(yè)務(wù)系統(tǒng)，業(yè)務(wù)絕對不是 1+1=2 這么簡單。
但即使這樣，在我經(jīng)歷最近一個短期項(xiàng)目，跟客戶合作開發(fā)的時候，又意識到 —— 即使是 簡單業(yè)務(wù)系統(tǒng)，如果開發(fā)人員沒有 建模意識、或者面向?qū)ο蟮慕?jīng)驗(yàn)、甚至說是沒有業(yè)務(wù)的理解消化能力，寫出的代碼甚至連 1+1=2 都做不到。

這個事情是這樣的。
背景：項(xiàng)目是做一款區(qū)塊鏈的手機(jī)錢包（當(dāng)然這里要說的與區(qū)塊鏈知識無關(guān)）。
可以簡單的理解一下 —— 每一個該APP的User可以通過”手機(jī)號+驗(yàn)證碼“登錄該APP，而每個User下可以有一批賬戶Account。
可以想象比對為，某銀行app的一網(wǎng)通賬號 -> User，一網(wǎng)通賬號下有多張銀行卡、信用卡賬戶 -> Account。
業(yè)務(wù)需求：進(jìn)入APP首頁的時候，首頁展示的”當(dāng)前Account“默認(rèn)為最近一次使用的Account。
實(shí)現(xiàn)背景：后臺保存數(shù)據(jù)狀態(tài)，使用的MySQL數(shù)據(jù)庫。（有一些其他背景，我這里就不另描述為何不采用APP前端保存等方式）
表結(jié)構(gòu)類似：

看到這里，每個人應(yīng)該內(nèi)心都有自己的實(shí)現(xiàn)方式了。
基于這是一個業(yè)務(wù)簡單的系統(tǒng)，可以嘗試直接用數(shù)據(jù)模型的形式表述一下。
是不是很簡單？

相信許多人都會覺得很簡單，它的確也挺簡單。
甚至，當(dāng)時在項(xiàng)目上第一版代碼實(shí)現(xiàn)出來的時候，即使code review沒有通過，我也沒有覺得它是個問題，即使實(shí)現(xiàn)方是客戶方的Dev。直到正式team code review，在與客戶方Dev的溝通中，我才發(fā)現(xiàn)，對一些Dev來說，它的確是一個問題。

那，看一下你的數(shù)據(jù)模型是下面哪一種：

很不幸，當(dāng)時的第一版代碼實(shí)現(xiàn)是 1。犯了將Account的屬性泄露到User中的大原則問題。
(排除)

再看下 2，"默認(rèn)賬戶"，這是個什么鬼？也許有人會說，這只是字段起名的問題。或者也有人會說，就是”默認(rèn)要顯示的賬戶“啊。相比于1，User和Account之間的關(guān)聯(lián)使用了id，比 1 要好很多。但是，User需要關(guān)心是哪個Account要顯示嗎？好，那我們先把 2 放一下。

那看下 3，每個account都有一個bool標(biāo)記，用以標(biāo)記自己是不是當(dāng)前User下的默認(rèn)賬號。好處是，User完全不用關(guān)心旗下的Account被選擇的問題。但，先不提 默認(rèn)賬戶 關(guān)鍵字的問題，可以想象一下，當(dāng)User切換了當(dāng)前的Account，系統(tǒng)是否就需要 整體檢查一遍當(dāng)前User下所有的Account的is_default值，并且進(jìn)行修改？雖然在并發(fā)競爭低的場景下，貌似也勉強(qiáng)勉強(qiáng)接受，再想一下是不是有更好的辦法？

最后看下 4，在 3 的基礎(chǔ)上再想一下，到底是什么決定了當(dāng)前User下一堆Account中那唯一一個true標(biāo)記的？這個時候 —— 請把，需求拿出來再仔細(xì)看一遍。
這很重要。

”進(jìn)入APP首頁的時候，首頁展示的當(dāng)前Account默認(rèn)為 最近一次使用 的Account?！?/p>

如果覺得不確定，甚至可以拉上team上的BA再認(rèn)真聊一下。
DEV：最近一次使用，意思是賬號的最近一次使用的時間點(diǎn)很重要？
BA：我不確認(rèn)”最近一次使用的時間點(diǎn)“是不是很重要。首頁這個場景下，我只關(guān)心顯示的是最后一次使用的賬號。但對于首頁上手動點(diǎn)擊切換Account的彈出層上，Account List我覺得倒是可以采用根據(jù)各自的 最近一次使用的時間點(diǎn) 來排序展示。

到這里，可以再拿出之前還沒完全排除掉的2、3、4，事情就很好解決了。2 和 3莫名其妙地突出了一個默認(rèn)賬號的問題，并且讓事情變得復(fù)雜，同時遺漏對了每個最近一次使用的時間點(diǎn)的記錄。而 4 在抓到最近一次使用的時間點(diǎn)這個關(guān)鍵信息，并且得到業(yè)務(wù)認(rèn)可的同時，解決了首頁展示的業(yè)務(wù)case，并且能很好的支持?jǐn)U展。

知識消化、理解業(yè)務(wù)意圖、分析建模、或者是whatever

上面的例子有點(diǎn)長，本人也比較擔(dān)心自己的表述不太好，讓舉證方向發(fā)展到比較奇怪的地方?；蛘?，有時候不同的人的經(jīng)歷總是可以看出不一樣的味道。

當(dāng)然，這篇博客的目的也并不是為了直奔DDD主題。
只是想要強(qiáng)調(diào)一點(diǎn)：寫業(yè)務(wù)代碼其實(shí)也沒那么簡單和單調(diào)。Dev在開發(fā)之前，或者是開發(fā)的過程中，都要確保自己對業(yè)務(wù)知識進(jìn)行了消化，掌握了業(yè)務(wù)意圖，然后進(jìn)行建模、實(shí)現(xiàn)開發(fā)。
即便是在不需要運(yùn)用DDD的簡單業(yè)務(wù)系統(tǒng)中。

最后引用《領(lǐng)域驅(qū)動設(shè)計(jì)與模式、原理與實(shí)踐》中的一句話：

代碼輸入并非交付產(chǎn)品的瓶頸；編碼是開發(fā)過程中最簡單的一部分。在非功能性需求之外創(chuàng)建并維持一個能夠滿足業(yè)務(wù)用例的領(lǐng)域的有用軟件模型才是難點(diǎn)所在。