來源：伯樂在線專欄作者 - 陳景廣

鏈接：http://blog./106141/

點擊 → 了解如何加入專欄作者

做業(yè)務(wù)的開發(fā)們,，幾乎都有一個做架構(gòu)的心，好的業(yè)務(wù)開發(fā)者不僅要能做好業(yè)務(wù),，更要能做好業(yè)務(wù)架構(gòu),。在現(xiàn)實中我們總會遇到大大小小的需求，那我們應(yīng)該怎么在滿足業(yè)務(wù)的同時又能作出很好的技術(shù)設(shè)計呢,。

1. 什么是好的技術(shù)設(shè)計

好的技術(shù)設(shè)計應(yīng)該很清楚的表達(dá)了：

• 要解決的問題

• 解決方法

• 各種解決方案的優(yōu)缺點對比

• 如何實施

2. 要解決的問題

要解決的問題,，其實就是需求是什么。很多人覺得提需求是產(chǎn)品經(jīng)理的事情,，和開發(fā)沒有什么關(guān)系,，開發(fā)人員只要寫代碼就可以了，實則不然,。產(chǎn)品經(jīng)理提出的需求和開發(fā)清楚理解要解決的問題,，還是有一段距離的。

最簡單的產(chǎn)品經(jīng)理提出需求：為用戶提供一個登錄界面,，可以在APP和微信上使用,，同時能夠防止機器人自動注冊。

2.1 拆解產(chǎn)品需求

說到產(chǎn)品需求,，就想起很多網(wǎng)上和工作中遇到的同事在吐槽產(chǎn)品經(jīng)理,，幾乎都是在吐槽產(chǎn)品經(jīng)理奇葩的需求和混亂的邏輯。我覺得出現(xiàn)這種需求卻能進入開發(fā)階段,，作為開發(fā)人員也是有責(zé)任的,。

我一直任務(wù)開發(fā)人員是要參與到產(chǎn)品需求中去的，這個在程序員的業(yè)務(wù)觀中也有詳細(xì)的闡述，這些是題外話,。

一般產(chǎn)品經(jīng)理提出的需求在技術(shù)人員來看都缺少足夠的細(xì)節(jié),，這種時候需要針對產(chǎn)品需求進行拆解，將需求拆解為更小的需求,，確認(rèn)其中的細(xì)節(jié),。例如針對登錄界面的需求就可以劃分為用戶登錄界面的基本邏輯和防機器人自動登錄/注冊的兩個子需求。

2.2 挖掘潛在需求

針對上面的兩個子需求,，我們繼續(xù)探究一下其中的潛在需求：

• 用戶登錄基面的正常邏輯里面需要確認(rèn)界面應(yīng)該是什么樣,，在不同平臺上的樣式有哪些差異。是否提供微信登錄,、微博登錄,、和qq登錄等第三方登錄平臺的登錄。

  
  

• 防機器人：使用何種方式防止機器人自動登錄和注冊,，使用驗證碼還是使用短信驗證碼,，不同驗證碼方式有哪些樣式需求。

這其中的很多細(xì)節(jié)都是隱含的,，有些是產(chǎn)品經(jīng)理自己能想到的,，有些是產(chǎn)品經(jīng)理模糊有個印象的，有些可能壓根就沒有想到的,，這時候需要技術(shù)人員一一確認(rèn)細(xì)節(jié),，補充豐富需求。

2.3 未來可能擴展的需求

針對用戶登錄這個需求,，未來可能需要,，在用戶登錄的時候?qū)⒂脩舻牡卿浬舷挛膮?shù)記錄下來，如用戶登錄ip,、登錄平臺,、微信登錄時的id信息等，并將這些作為用戶的特征信息記錄下來并廣播出去,，供其他業(yè)務(wù)模塊做邏輯判斷的條件之一,。

比如，未來可能針對微信端登錄的用戶,，給這部分用戶發(fā)抵用券等行為,。

2.4 確定需求

拆解并細(xì)化了產(chǎn)品需求，但并不是所有的需求都要在這一次實現(xiàn),，需要最后跟產(chǎn)品確認(rèn)這一次需要實現(xiàn)的需求,。

確定需求的過程時常成為和產(chǎn)品經(jīng)理PK的過程，在PK的過程中最重要的是產(chǎn)品的價值和實現(xiàn)的成本,，在這兩方面獲得一個平衡,。以這個需求為例,，微博登錄相比微信登錄就不是一個很有價值的需求，針對這種需求如果時間太緊就可以PK掉了,。

確認(rèn)了需求,，我們的技術(shù)設(shè)計也就完成了一半。 這樣說來一些技術(shù)人員可能會覺得有些夸張,，但實際工作中,，不同的需求真的可能完全改變技術(shù)方案，——比如在關(guān)于微信的一點思考文中,，提到Slack和微信關(guān)于聊天記錄的不同而導(dǎo)致技術(shù)上實現(xiàn)成本大增,，且實現(xiàn)重點都會發(fā)生很大的變化。

為了便于后面討論,，我們例子中的產(chǎn)品需求定位下來只提供用戶登錄,，和短信驗證碼驗證。

3. 解決方案

3.1 業(yè)務(wù)領(lǐng)域的劃分

現(xiàn)在的技術(shù)大趨勢是采用服務(wù)化的方式實現(xiàn)業(yè)務(wù),，正確劃分業(yè)務(wù)領(lǐng)域也是實現(xiàn)服務(wù)化基礎(chǔ)之一,。

現(xiàn)在微服務(wù)的概念越來越火，服務(wù)按照什么維度劃分才算是“微”,，到現(xiàn)在還沒有什么標(biāo)準(zhǔn),，不同的實踐會有適合自己的劃分方式；按照業(yè)務(wù)領(lǐng)域劃分服務(wù),，可以保證一個服務(wù)能夠提供一個業(yè)務(wù)領(lǐng)域的支持，更利于業(yè)務(wù)管理和服務(wù)規(guī)劃,。同時微服務(wù)也是一種運維概念,，將每個微服務(wù)單獨部署，但這種方式會導(dǎo)致機器很多,，對運維是一個巨大挑戰(zhàn),，在遇到線上問題時也是一種巨大的挑戰(zhàn)。因此按照業(yè)務(wù)領(lǐng)域來組織更細(xì)粒度的服務(wù),，如訂單項目中包含創(chuàng)建訂單服務(wù),、訂單查詢服務(wù)和訂單修改服務(wù)等，做統(tǒng)一發(fā)布管理,。

業(yè)務(wù)領(lǐng)域劃分,，首先需要從需求角度來分析。如例子中的需求主要包含用戶登錄和短信驗證碼兩個方式,。

• 從業(yè)務(wù)角度來看,，其使用場景是用戶，從使用場景來說更適合在用戶服務(wù)上,，細(xì)分下來可以劃分到用戶登錄服務(wù),；短信驗證碼在這個需求的使用場景,，面向?qū)ο笠彩瞧胀ㄓ脩簦谶@個需求里來看,，劃分到用戶服務(wù)領(lǐng)域沒有什么大的問題,。
  但是長遠(yuǎn)來看，短信驗證功能不僅僅會用在用戶登錄,，也可以用在商戶登錄,、用戶注冊、用戶修改密碼,、用戶領(lǐng)券驗證等場景,，面向的對象也不單單是普通用戶，可能有商戶等等,。因此長遠(yuǎn)來看短信驗證劃歸到用戶服務(wù)里是不合適的,。

  
  

• 劃分業(yè)務(wù)領(lǐng)域，不單單要從業(yè)務(wù)角度,，還要從系統(tǒng)規(guī)劃角度來分析：
  例如這里的短信驗證服務(wù),，因為會出現(xiàn)多個復(fù)用的場景，且其業(yè)務(wù)領(lǐng)域更偏重于驗證,，因此將驗證服務(wù)與用戶登錄服務(wù)獨立,，使用服務(wù)調(diào)用的方式來實現(xiàn)復(fù)用，更便于以后的系統(tǒng)發(fā)展,。

實際項目中劃分業(yè)務(wù)領(lǐng)域不會像例子中那么界線分明,，項目中的業(yè)務(wù)領(lǐng)域相互有包含關(guān)系，業(yè)務(wù)邊界有交叉甚至有相似之處,，但從業(yè)務(wù)和系統(tǒng)的角度深入分析,，才能慢慢厘清其中的關(guān)系。

3.2 數(shù)據(jù)模型

業(yè)務(wù)領(lǐng)域模型和數(shù)據(jù)模型共同構(gòu)成了系統(tǒng)業(yè)務(wù)模型,。數(shù)據(jù)模型是數(shù)據(jù)庫系統(tǒng)的核心和基礎(chǔ),，在設(shè)計中使用E-R圖的方式來展示數(shù)據(jù)模型。

業(yè)務(wù)模型抽象出來之后,，我們的數(shù)據(jù)庫表的設(shè)計也就基本有出來了,，只要再根據(jù)業(yè)務(wù)需求進行合理的字段冗余和索引設(shè)計就形成了基本的數(shù)據(jù)表。為了應(yīng)對高并發(fā)需求,，數(shù)據(jù)庫會進行分庫分表的處理,；前文說道的業(yè)務(wù)領(lǐng)域劃分，在數(shù)據(jù)表上就是垂直分表的體現(xiàn),。

3.3 服務(wù)關(guān)系

厘清了業(yè)務(wù)領(lǐng)域和業(yè)務(wù)模型,，各服務(wù)之間的依賴關(guān)系也就非常清晰了。在本文的例子里,，用戶登錄服務(wù)直接依賴短信驗證服務(wù),。在技術(shù)設(shè)計中,，不單單需要厘清本次需求涉及到的服務(wù)相互關(guān)系，還需要理出受影響服務(wù)的關(guān)系,，避免因為新增業(yè)務(wù)而打亂服務(wù)之間的關(guān)系,。

3.3 接口設(shè)計

在技術(shù)設(shè)計中，接口設(shè)計應(yīng)該是自然而言的過程,，很多時候api設(shè)計也并不一定是必須的,；真正在實施過程中，api的定義不可避免的會出現(xiàn)微調(diào),。

幾個api設(shè)計的坑點：

• 提供適當(dāng)?shù)呐坎樵兘涌?。比如批量查詢用戶信息等這種基礎(chǔ)性的查詢。

  
  

• 服務(wù)在接口層有自我保護,。如批量查詢接口,，需要控制批量查詢的規(guī)模，過大規(guī)模的查詢不單單會對自身系統(tǒng)造成很大的壓力,，在數(shù)據(jù)傳輸過程中也會大量占用網(wǎng)絡(luò)帶寬,。

  
  

• api根據(jù)使用業(yè)務(wù)場景分類。比如現(xiàn)在電商中時常使用的立減,，在展示測的立減展示服務(wù)和在支付時的使用立減服務(wù),，就是兩個不同的使用場景。不同的使用場景對服務(wù)的要求是完全不一樣的,，立減展示更多偏重于信息展示,，同樣是要請求立減金額，在實現(xiàn)上可以使用緩存,，也能容忍一定程度的數(shù)據(jù)金額不一致,；但在立減使用場景下，在請求立減金額時卻需要嚴(yán)格的校驗使用規(guī)則,，且需要獲取實時的立減金額。

3.4 業(yè)務(wù)流程Demo

到此為止,，系統(tǒng)的整體已經(jīng)完成了,，這時候應(yīng)該已經(jīng)能夠滿足業(yè)務(wù)需求了，可以根據(jù)實際中的業(yè)務(wù)流程來實驗一下我們的系統(tǒng)了,。

業(yè)務(wù)流程demo可以采用UML時序圖的方式來檢驗,，系統(tǒng)中每個流程跑下來，就可以看到對每個接口的調(diào)用情況和對數(shù)據(jù)庫的訪問情況,。

4. 實施方案

有了業(yè)務(wù)系統(tǒng)設(shè)計,，剩下的就是要怎么實施了。實施中會牽涉到參與開發(fā)人員,、具體的時間節(jié)點已經(jīng)模塊劃分等,，這些和每個開發(fā)團隊自身情況非常相關(guān),，在這里不再多說。這里主要說說系統(tǒng)的上線方案和回滾方案,。

• 上線方案

  
  系統(tǒng)如何上線,？如果只是新項目上線，那只要按照項目依賴關(guān)系依次上線就可以了,。但如果涉及到老接口的修改和在線數(shù)據(jù)模型的修改,，就會牽涉到新舊邏輯兼容的問題?；叶壬暇€,，需要考慮到新數(shù)據(jù)舊流程、新數(shù)據(jù)新流程,、舊數(shù)據(jù)舊流程和舊數(shù)據(jù)新流程的業(yè)務(wù)邏輯,。

  
  

• 回滾方案回滾是上線的逆流程，針對新系統(tǒng)上線的回滾中,，只需要關(guān)閉入口,、沒有新數(shù)據(jù)進入就可以按照上線順序逆序依次回滾。但針對老接口修改和在線數(shù)據(jù)模型修改時,，同樣需要考慮新數(shù)據(jù)舊流程,、新數(shù)據(jù)新流程、舊數(shù)據(jù)舊流程和舊數(shù)據(jù)新流程的業(yè)務(wù)邏輯,。