這里是Z哥的個人公眾號

每周五11：45 按時送達

當然了，也會時不時加個餐～

我的第「165」篇原創(chuàng)敬上

大家好，我是Z哥。

相信每一位真正的程序員心里都有這樣一個念想：只要我的技術夠牛，就能驅(qū)動業(yè)務的發(fā)展。

但是往往我們在不自覺間做的是背道而馳的事情。

業(yè)務：我希望在這個報表里多展示某個字段行不行？現(xiàn)在每次我都得手動把數(shù)據(jù)合并一下，有點麻煩。

技術：這個字段不在我們的系統(tǒng)里，要加上的話，我們需要從別的業(yè)務系統(tǒng)拿數(shù)據(jù)，比較麻煩，而且可能準確性和及時性都會差一些。如果非要加的話，開發(fā)工期會比較久，你需要走需求流程。

業(yè)務：啊，不是吧。多個字段顯示，有這么難嗎？

業(yè)務：用戶反饋這個活動鏈接分享給他的好友后他們點開是空白的。

技術：這個活動本身是站內(nèi)活動，我們沒考慮會分享到站外的情況，所以這里信息校驗沒通過，導致頁面數(shù)據(jù)沒有返回給客戶端，造成了打開空白的情況。

業(yè)務：其實我只想知道……現(xiàn)在要怎么解決？

上面的這些景象是不是很熟悉呢？

那么技術驅(qū)動業(yè)務到底是不是存在呢？答案是肯定的。Z哥我認為，主要體現(xiàn)在以下兩個目標：

解決過去無法解決的問題

讓解決問題的效率大大提升

但是我們仔細來思考一下這兩個目標。

首先，「解決過去無法解決問題」?！斑^去無法解決”這六個字就已經(jīng)勸退99%的人了，這里面一部分人的想法是：過去無法解決，現(xiàn)在肯定也沒法解決，算了。另一部分人甚至完全看不到這里存在問題，因為潛意識已經(jīng)默認這個問題本就是現(xiàn)實的一部分。

其次，「讓解決問題的效率大大提升」。這幾乎肯定不是小打小鬧能實現(xiàn)的，必然要從一個新的思路來解決問題才有可能。然而，人的思維慣性會阻礙新思路的產(chǎn)生，很少有人可以跳脫出現(xiàn)有解決方案的框架來重新考慮問題。

所以真正能做到技術驅(qū)動業(yè)務的關鍵并不在于你的技術有多牛，而是思維能否跳脫出過去的束縛，并且要擁有業(yè)務感覺，要懂業(yè)務。因為從概念上來說，業(yè)務是“釘子”，技術是“錘子”，前者是問題，后者是問題的解決方案。

其實，先不要說能「驅(qū)動業(yè)務」，能做好「支撐業(yè)務」的人我覺得就是一位優(yōu)秀的程序員了，因為要達到這點也不容易。具體可以從以下三個方面入手。

/01? 理解業(yè)務/

如果你無法吃透業(yè)務，真正理解業(yè)務，那么別說驅(qū)動業(yè)務了，你能把業(yè)務實現(xiàn)到預期的80%都不錯了，就像上面提到的第二段對話。

當然技術人員對業(yè)務的理解方式和業(yè)務方、產(chǎn)品經(jīng)理并不完全相同。最大的區(qū)別在于，技術人員需要對業(yè)務的“不可見”部分了解更多。比如，多個環(huán)節(jié)背后的流轉(zhuǎn)過程，這會影響你的技術實現(xiàn)和程序設計。

對于這個方面，Z哥只給你一個建議，不管你用什么方式方法來理解業(yè)務，你一定要帶著：這個業(yè)務的提出是為了解決什么問題或者實現(xiàn)什么目的？

要做到這點有難度，因為大家的本位意識會讓你習慣于盯著開發(fā)工期、deadline這種方面。但是只要你能帶著這個角度去思考，至少可以將業(yè)務實現(xiàn)地無限接近預期的100%。

不過，理解業(yè)務最多算是一個目標校準的工作，而且還沒涉及到技術。我們要做好「支持業(yè)務」甚至是「驅(qū)動業(yè)務」的動力源還是在技術方面。

/02? 穩(wěn)健、可擴展的基礎架構/

能夠支撐或者驅(qū)動業(yè)務的首要前提，必須是你的“地基”不但穩(wěn)固而且要領先于業(yè)務去規(guī)劃。所以底層的基礎架構設計非常重要，如果視野僅僅關注“這個需求該怎么實現(xiàn)”自然達不到這樣的效果。

這一點需要提升你的軟件設計意識。簡單的像設計模式之類的，復雜一些的則需要你吃透一些經(jīng)典的設計原則和設計思想背后的優(yōu)缺點和適用場景。

常見的設計原則：

• SRP 單一職責

• OCP 開閉原則

• LSP 里氏替換原則

• DIP 依賴倒置原則

• ISP 接口隔離原則

這些設計原則都有標準的定義，我就不一一列出來了，不清楚的可以自行網(wǎng)上搜索。

常見的設計思想：

• 分層架構

• 六邊形架構

• 洋蔥架構

• 領域驅(qū)動設計

這里的每一個設計思想，都夠?qū)懞脦灼恼?#xff0c;我這里就不展開了。

/03? 構建完備的領域模型/

上面的四個設計思想，要我說哪個最有用，肯定是DDD。最近幾年DDD也被炒的非常火。

這里的領域模型就是DDD中的概念。

我算是國內(nèi)比較早一批接觸DDD并運用的人，大概在2014年的時候機緣巧合了解到了DDD，然后啃了兩本最經(jīng)典的書，當時給我一種看到世外桃源的感覺（真實感受，不夸張）。

它讓代碼里的model變得有血有肉，好像你在設計一個虛擬城市一樣。這里需要擺一個物件，那么它需要長成什么樣子，你要盡可能詳細的描繪出來；那里需要擺一個人物，那么他長什么樣子，當時正在做什么事，也得描繪出來。

DDD讓你摒棄了傳統(tǒng)三層架構以數(shù)據(jù)表為核心的代碼設計方式，可以讓業(yè)務含義更多地體現(xiàn)在代碼中。如此的好處很明顯，就是你的代碼可擴展性必然很強，因為你的一個model體現(xiàn)了現(xiàn)實世界中所代表的對象，現(xiàn)實中的對象多了一種行為，那么給這個model增加一個對應的function就好。

如果你是一位DDD（領域驅(qū)動設計）新手，并對DDD感興趣，可以翻閱我2016年寫DDD系列文章《如何一步一步用DDD設計一個電商網(wǎng)站》來入門。（當時還沒開通公眾號，所以你得到我的博客去看：zacharyfan.com）

不過里面有些內(nèi)容在后來我有新的理解，但并沒有更新。不過這不影響你體會DDD的優(yōu)雅，所以你還是可以看看。

當你做好了前面的3步， 你就具備了驅(qū)動業(yè)務的前提條件。

懂業(yè)務。

基礎架構夠穩(wěn)、彈性夠強。

現(xiàn)實的問題在技術維度上體現(xiàn)的夠清楚。

在這之上你就可以嘗試基于對領域模型的觀察找到前面提到的技術能夠驅(qū)動業(yè)務的兩個目標：

當前無法解決的問題

當前解決效率不高地方

好了總結(jié)一下。

這篇呢，Z哥和你分享了我對技術驅(qū)動業(yè)務這件事的看法。

我認為技術驅(qū)動業(yè)務的關鍵并不在于技術多好，而在打破慣性思維和對業(yè)務的理解深度上。

所以，如果你想真正做到驅(qū)動業(yè)務，不妨先將以下3點基礎工作做好，否則只是空想而已。

理解業(yè)務

穩(wěn)健、可擴展的基礎架構

構建完備的領域模型

希望對你有所啟發(fā)。

推薦閱讀：

• 好的自我介紹，面試成功一大半
  

• 軟件如何優(yōu)雅地向前兼容？
  

原創(chuàng)不易，如果你覺得這篇文章還不錯，就「在看」或者「分享」一下吧。鼓勵我的創(chuàng)作 ：）

如果你有關于軟件架構、分布式系統(tǒng)、產(chǎn)品、運營的困惑

可以試試點擊「閱讀原文」

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的心想技术驱动业务，却在背道而驰的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。