《架構漫談》讀書筆記十一

新發明輪子

Business Domain至關於人的大腦，而Service，Repository，Glue Code等部分所採用的技術，所有都是計算機本身領域的技術，都是爲了可以讓程序跑起來，至關於人的四肢。咱們大部分開發人員的工做主要專一於四肢部分。咱們真正應該投入的是大腦部分。由於大腦可以決定四肢長什麼樣，而不是反過來。不少架構師、技術人員主要專一於計算機相關的技術，忽略了業務自己，甚至看不起業務，這也是爲何技術老是和業務衝突的緣由。

架構師應該承擔起解決業務問題的這個角色來，專一於Business Domain和軟件自己的架構，讓技術人員致力於爲業務在計算機中跑起來而努力。只有把這二者很好的結合起來，才能更好地完成業務的目標，纔會讓軟件更好地服務於你們。最終必定會獲得一個很好的軟件架構，令軟件開發團隊和業務部門都可以很好地開展工做並下降成本。

當現有已經存在不少技術，而這些技術卻和咱們所要解決的問題並非那麼直接對應的時候，咱們就須要有意識的組織和識別不一樣的技術，來實現業務的目標。這個時候組織的方式有不少種，其中成本最低的方法就是按照要達成的目的和當前的問題，從上到下進行架構分拆。分拆出來的更細粒度的問題，分解到不一樣的人來進行解決，就造成了業務架構和組織架構。解決這些問題就須要組合不少不一樣的技術，那麼應該採用哪些技術？仍是本身重頭實現一個？ 本身實現一個—這就是不少人所謂的從新發明輪子。如下試着分析一下：

當技術所解決的問題和分拆出來要解決的問題，徹底匹配的時候，這是最完美的。好比須要提供web要訪問的service，不少MVC的framework就能夠很好的知足這一點。而這個時候若是非要本身實現一個，頗有可能就是從新發明輪子。

當技術所提供的能力遠遠超過須要解決的問題時，每每掌握技術和維護技術會成爲瓶頸。由於越複雜的技術，成本越高。若是本身實現一個僅僅是解決當前問題的方案，可能成本反而更低。這也是爲何不少大型的互聯網公司不斷地開源出來本身的技術的緣由。而這些技術對於咱們來講是否適用？他們本來是用來解決誰的問題的？什麼問題？若是不清楚這些，就冒然採用，可能會致使更高的成本。

當技術所提供的能力和咱們所要解決的問題部分匹配時，仍是要當作本。好比當咱們須要一個錘子的時候，手邊正好沒有，可是卻有一隻高跟鞋，勉強也能夠替代錘子。可是長期來看，這麼用不划算，由於高跟鞋的價格比錘子高不少，耐用性差不少，維護成本也高不少。

因此，準確識別採用什麼技術的能力，也是架構師所要具有的能力之一。考慮的主要因素也是長期的成本和收益。