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

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

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

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

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

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

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

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

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

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

.NET

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

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

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