資深Java架構(gòu)師經(jīng)驗之談？

作為一個資深的互聯(lián)網(wǎng)從業(yè)者，我要非常負(fù)責(zé)任的說，項目的好壞最根本的在于市場，而不是單純的技術(shù)。

不可否認(rèn)，技術(shù)對于一個產(chǎn)品來說非常重要，曾幾何時，我也是非常的追求技術(shù)上的“高端”從而忘記了產(chǎn)品與市場、時間上的問題。因此，由于技術(shù)上的某些原因，導(dǎo)致了項目的延期甚至上線后發(fā)生一些比較嚴(yán)重的Bug。

后來，隨著工作的時間越來越長，對于技術(shù)和產(chǎn)品的觀念慢慢發(fā)生著改變。后來，我在一次工作中的經(jīng)歷，讓我確實的認(rèn)識到了，技術(shù)是為產(chǎn)品和市場服務(wù)的。

那時，我作為一個項目的負(fù)責(zé)人，全權(quán)對項目負(fù)責(zé)，為了讓項目能夠更快的上線，我使用了最簡單的技術(shù)方案，使用最少的人力，讓項目快速的上線了。由于項目的發(fā)展比較快，后期還上了物聯(lián)網(wǎng)設(shè)備，使得在不斷的迭代過程中，曾經(jīng)的架構(gòu)慢慢的無法支撐業(yè)務(wù)的增長。

這時，就面臨需要重構(gòu)了，而這個時期，團(tuán)隊有兩個聲音，一個覺得應(yīng)該使用領(lǐng)域驅(qū)動設(shè)計（DDD）和查詢和命令職責(zé)分離（CQRS）來重構(gòu)，理由是因為，我們團(tuán)隊曾經(jīng)對DDD有一定的研究，而且經(jīng)過這么長時間，對于業(yè)務(wù)的理解已經(jīng)非常深了，使用DDD能夠很好的鍛煉團(tuán)隊，并且讓產(chǎn)品的技術(shù)底蘊很深厚。另一個是覺得，我們應(yīng)該在服務(wù)化上做更多的優(yōu)化，不改變現(xiàn)有的底層架構(gòu)。

當(dāng)然，我個人是不建議用DDD的，因為我當(dāng)時自己對DDD的理解都不深，我相信團(tuán)隊大部分的人對于DDD都是一知半解，潛在的風(fēng)險太大了。

但是，老板估計對現(xiàn)有的架構(gòu)不是很滿意，加上另一個技術(shù)的負(fù)責(zé)人大力的推薦DDD，因此最終就使用了這個方案，這導(dǎo)致使用了大量的人力在項目的重構(gòu)上，對于業(yè)務(wù)上的迭代速度變得相當(dāng)?shù)穆?個半月以后，業(yè)務(wù)的壓力直接導(dǎo)致了這次重構(gòu)的版本夭折了。

這次經(jīng)歷，讓我在技術(shù)選型的時候更加的謹(jǐn)慎了，盡量不去使用自己不熟悉的技術(shù)方案，技術(shù)的創(chuàng)新前，需要做大量的實驗。

再后來，我遇到了一個豐田的技術(shù)人員，他是做豐田的物流系統(tǒng)的。豐田的物流體系是全球數(shù)一數(shù)二的，也是少有的能夠做到準(zhǔn)時制物流的公司。按道理，這樣龐大的系統(tǒng)，架構(gòu)應(yīng)該是非常復(fù)雜的才對。

但是，我在詳細(xì)的了解后發(fā)現(xiàn)，并不是這樣的。豐田的物流系統(tǒng)使用

.NET

做的，基礎(chǔ)的三層架構(gòu)，連MVC都沒有使用，甚至連分布式緩存都沒有使用，性能差了，就加服務(wù)器。

豐田本來就不是一個互聯(lián)網(wǎng)公司，是全球最大的汽車制造商，自然不愿意花太多錢養(yǎng)太多技術(shù)人員，但是服務(wù)器多花點錢是沒關(guān)系的。這樣技術(shù)方案其實是最適合豐田的，語氣花一年上千萬養(yǎng)一大群高端的技術(shù)人員，不如花幾百萬還買服務(wù)器呢。

因此，項目的好壞其實更多的還是看看這個項目是不是符合用戶的需求，能不能解決用戶的痛點，技術(shù)上是不是最適合產(chǎn)品的定位。并不是技術(shù)越高端就是越好的，而作為架構(gòu)師，除了了解技術(shù)外，還需要了解業(yè)務(wù)，只有明白了業(yè)務(wù)的發(fā)展，才能夠做出最適合的架構(gòu)。