溪雲閣：專注程式設計教學，架構，JAVA，Python，微服務，機器學習等領域，歡迎關注，一起學習。
有本書說：會使用框架不一定能成為一個優秀的架構師，但優秀的架構師一定會使用框架。架構師除了會使用工具，還需要有架構設計思想和效能調優技能。在設計上追求簡單有效，不做過度設計。
企業級別總體架構設計
目前很多企業都是以專案為主，一個專案撐起整片天的大把存在，這樣的情況在設計上需要非常把握一個度，儘可能以專案為導向做到點到即可，年輕人要講武德。但是當我們有了幾十個，幾百個甚至上千個應用的時候，此時需要的不單單是單個專案設計，更需要整個企業級別的總體規劃及總體設計，在這個上面需要做頂層思考與設計。
大公司有大公司的好，小公司有小公司的溫暖，大公司很多時候人情冷暖心裡自知，小公司小團隊常常存在家庭般的體貼。在大公司裡面做技術，由於公司體積龐大導致經常難以看到這個商業的全貌，在規劃上非常吃虧，除非站在非常高的層面去俯瞰整個體系；小公司又缺乏最基礎的流量及各種中介軟體的應用場景，或者在使用了某些技術框架後也只是存在單純意義上的使用，不是為了貼近業務場景；中型公司基本上針對這兩者都能兼顧到，此時在做整體的企業級架構設計的時候往往比較容易落地。
說起來簡單做起來難，落地這兩個字是非常考驗能力，整個企業整體架構設計需要在技術，管理，業務三方做取捨，遊刃有餘的同時又能動態切換，架構師在設計上還包含業務架構，應用架構，資料架構，技術架構4種，但是現在很多都是總包做，沒辦法的事。
靈魂所在的應用架構
小孩子學畫畫從來都是從一張白紙開始，一筆一畫進行塗鴉。在專案或者企業的開始階段，應用架構的設計就跟小孩子畫畫一樣都是從一張白紙開始，也是一個不斷試錯、不斷進化的過程。這樣子的架構其實就是起到一個承上啟下的作用，承接功能需求，下連程式碼編寫，這就是應用架構靈魂所在，它是最快能體現出價值的東西。
從功能設計來分析設計，涉及到各類UML圖，領域圖，整體架構分層，核心元件或者程式碼的編寫，這些都是緊密結合並如銅環般串起來，環環相扣。整體的架構關注點永遠在於職責問題、領域邊界、應用關係、儲存設計、部署。
任何東西都是可大可小，做大了做複雜了容易增加開發人員的壓力，直接導致專案延期。每一個應用的分層，需要做到簡單有效，易用學習成本低，業務場景支援性強等。在我們設計上，參考了DDD的邊界思想設計好我們的介面邊界，並限定統一的出參入參來進行區分處理，這樣子的設計其實就是還原了機器最原始的輸入輸出設計。
人都是懶惰的，特別是研發人員，總想著我做了一個東西后面不用寫了，所有的東西都來複用它；但是研發人員又是最勤奮的，他們想方設法做了一個適應了所有方法的東西，花費了巨大的時間。其實這種設計往往帶有很大的危險性，容易在後面的運維上增加運維的時間並且讓這個系統的複雜度變得非常高。
從架構到“管理”
任何架構都是要落地的、要標準化、要不斷演化的，這部分是需要通過融合技術架構與組織架構來實現。每一個角色的轉化，從架構師到技術管理，所關注的角度跟層面並不一樣，單純的留在技術層面演化成關注技術在商業的應用價值，技術跟業務的契合度，整個技術團隊的文化、能力不斷成長。
微服務的出現是個契機也是個痛苦的根源所在。很多企業剛開始使用最簡單的單體架構，開始往微服務架構遷移，這就是技改的過程。這樣子的過程無論專案大小都是痛苦的，專案小投入少但是微服務所需要的資源多，專案小涉及到的業務量多，很容易變成為了不影響業務而小改，不敢全盤推倒去做而採用慢慢吞併方式去做，最終變成單體與微服務並行的存在，你卻又無可奈何並且筋疲力勁不想繼續做，反正對上層的領導有交代就行，他們更加關注的就是系統，業務的穩定性。
技改其實並不是單純的技術改造，而是道路的演變，但是技改無論對大公司或者小公司而言，都是非常痛苦的，“小賭怡情，大賭傷財”。那什麼樣的技改才是正確之路，應該是能驅動公司業務發展的技改才是正確之路，讓技術與業務互相融合，互相匹配，同時技改的時候一定要尊重食物的發展規律，不要為了技改而技改，那就純粹為了炫技。這讓我想起以前面試過一家公司，從各類語言問到架構，從架構問到資料科學，範圍很廣，技術很牛逼，一問沒啥量，一年頂了天就1T非架構化資料，量能也就不到上萬人。WTF，垃圾。
每一個技術團隊都是可愛的，不像外面穿的死氣沉沉，如果一個部門整天都是死氣沉沉，那就是這個部門領導有問題，讓整個部門充滿激情活力，從固步自分到分享為樂，這就是團隊文化的建設。信任是團隊非常重要的存在，只有這樣子出來的團隊文化，才能真正留得住人。