這裏是Z哥的我的公衆號程序員
每週五11：45 按時送達面試
固然了，也會時不時加個餐～設計模式
個人第「165」篇原創敬上架構
你們好，我是Z哥。
框架
相信每一位真正的程序員內心都有這樣一個念想：只要個人技術夠牛，就能驅動業務的發展。分佈式
可是每每咱們在不自覺間作的是背道而馳的事情。網站
業務：我但願在這個報表裏多展現某個字段行不行？如今每次我都得手動把數據合併一下，有點麻煩。架構設計
技術：這個字段不在咱們的系統裏，要加上的話，咱們須要從別的業務系統拿數據，比較麻煩，並且可能準確性和及時性都會差一些。若是非要加的話，開發工期會比較久，你須要走需求流程。設計
業務：啊，不是吧。多個字段顯示，有這麼難嗎？3d
業務：用戶反饋這個活動連接分享給他的好友後他們點開是空白的。
技術：這個活動自己是站內活動，咱們沒考慮會分享到站外的狀況，因此這裏信息校驗沒經過，致使頁面數據沒有返回給客戶端，形成了打開空白的狀況。
業務：其實我只想知道……如今要怎麼解決？
上面的這些景象是否是很熟悉呢？
那麼技術驅動業務究竟是不是存在呢？答案是確定的。Z哥我認爲，主要體如今如下兩個目標：
解決過去沒法解決的問題
讓解決問題的效率大大提高
可是咱們仔細來思考一下這兩個目標。
首先，「解決過去沒法解決問題」。「過去沒法解決」這六個字就已經勸退99%的人了，這裏面一部分人的想法是：過去沒法解決，如今確定也無法解決，算了。另外一部分人甚至徹底看不到這裏存在問題，由於潛意識已經默認這個問題本就是現實的一部分。
其次，「讓解決問題的效率大大提高」。這幾乎確定不是小打小鬧能實現的，必然要從一個新的思路來解決問題纔有可能。然而，人的思惟慣性會阻礙新思路的產生，不多有人能夠跳脫出現有解決方案的框架來從新考慮問題。
因此真正能作到技術驅動業務的關鍵並不在於你的技術有多牛，而是思惟可否跳脫出過去的束縛，而且要擁有業務感受，要懂業務。由於從概念上來講，業務是「釘子」，技術是「錘子」，前者是問題，後者是問題的解決方案。
其實，先不要說能「驅動業務」，能作好「支撐業務」的人我以爲就是一位優秀的程序員了，由於要達到這點也不容易。具體能夠從如下三個方面入手。
/01 理解業務/
若是你沒法吃透業務，真正理解業務，那麼別說驅動業務了，你能把業務實現到預期的80%都不錯了，就像上面提到的第二段對話。
固然技術人員對業務的理解方式和業務方、產品經理並不徹底相同。最大的區別在於，技術人員須要對業務的「不可見」部分了解更多。好比，多個環節背後的流轉過程，這會影響你的技術實現和程序設計。
對於這個方面，Z哥只給你一個建議，無論你用什麼方式方法來理解業務，你必定要帶着：這個業務的提出是爲了解決什麼問題或者實現什麼目的？
要作到這點有難度，由於你們的本位意識會讓你習慣於盯着開發工期、deadline這種方面。可是隻要你能帶着這個角度去思考，至少能夠將業務實現地無限接近預期的100%。
不過，理解業務最多算是一個目標校準的工做，並且還沒涉及到技術。咱們要作好「支持業務」甚至是「驅動業務」的動力源仍是在技術方面。
/02 穩健、可擴展的基礎架構/
可以支撐或者驅動業務的首要前提，必須是你的「地基」不但穩固並且要領先於業務去規劃。因此底層的基礎架構設計很是重要，若是視野僅僅關注「這個需求該怎麼實現」天然達不到這樣的效果。
這一點須要提高你的軟件設計意識。簡單的像設計模式之類的，複雜一些的則須要你吃透一些經典的設計原則和設計思想背後的優缺點和適用場景。
常見的設計原則：
SRP 單一職責
OCP 開閉原則
LSP 里氏替換原則
DIP 依賴倒置原則
ISP 接口隔離原則
這些設計原則都有標準的定義，我就不一一列出來了，不清楚的能夠自行網上搜索。
常見的設計思想：
分層架構
六邊形架構
洋蔥架構
領域驅動設計
這裏的每個設計思想，都夠寫好幾篇文章，我這裏就不展開了。
/03 構建完備的領域模型/
上面的四個設計思想，要我說哪一個最有用，確定是DDD。最近幾年DDD也被炒的很是火。
這裏的領域模型就是DDD中的概念。
我算是國內比較早一批接觸DDD並運用的人，大概在2014年的時候機緣巧合瞭解到了DDD，而後啃了兩本最經典的書，當時給我一種看到世外桃源的感受（真實感覺，不誇張）。
它讓代碼裏的model變得有血有肉，好像你在設計一個虛擬城市同樣。這裏須要擺一個物件，那麼它須要長成什麼樣子，你要儘量詳細的描繪出來；那裏須要擺一我的物，那麼他長什麼樣子，當時正在作什麼事，也得描繪出來。
DDD讓你摒棄了傳統三層架構以數據表爲核心的代碼設計方式，可讓業務含義更多地體如今代碼中。如此的好處很明顯，就是你的代碼可擴展性必然很強，由於你的一個model體現了現實世界中所表明的對象，現實中的對象多了一種行爲，那麼給這個model增長一個對應的function就好。
若是你是一位DDD（領域驅動設計）新手，並對DDD感興趣，能夠翻閱我2016年寫DDD系列文章《如何一步一步用DDD設計一個電商網站》來入門。（當時還沒開通公衆號，因此你獲得個人博客去看：zacharyfan.com）
不過裏面有些內容在後來我有新的理解，但並無更新。不過這不影響你體會DDD的優雅，因此你仍是能夠看看。
當你作好了前面的3步， 你就具有了驅動業務的前提條件。
懂業務。
基礎架構夠穩、彈性夠強。
現實的問題在技術維度上體現的夠清楚。
在這之上你就能夠嘗試基於對領域模型的觀察找到前面提到的技術可以驅動業務的兩個目標：
當前沒法解決的問題
當前解決效率不高地方
好了總結一下。
這篇呢，Z哥和你分享了我對技術驅動業務這件事的見解。
我認爲技術驅動業務的關鍵並不在於技術多好，而在打破慣性思惟和對業務的理解深度上。
因此，若是你想真正作到驅動業務，不妨先將如下3點基礎工做作好，不然只是空想而已。
理解業務
穩健、可擴展的基礎架構
構建完備的領域模型
但願對你有所啓發。
推薦閱讀：
原創不易，若是你以爲這篇文章還不錯，就「在看」或者「分享」一下吧。鼓勵個人創做 ：）
若是你有關於軟件架構、分佈式系統、產品、運營的困惑
能夠試試點擊「閱讀原文」