架構漫談4
2020.4.11
架構漫談（九
）第九節講的是理清技術、業務和架構的關係。在軟體設計開發的過程中經常會看到，很多所謂的架構討論實際上只是在討論某種技術。在很多人的概念裡面，架構和技術實際上是等同的。學會了幾種技術，就認為自己是架構師了，甚至是學習的技術越多，就覺得自己的水平越高。這樣實際上是對自己很不負責任的。
技術與技術之間，有兩種關係：一種是在解決同乙個業務問題的前提下，更高效，更低成本的技術，會淘汰低效，高成本的技術。這是人類利益訴求所決定的。另一種是一般剛開始解決根本問題的技術（鑽木取火）的效率是比較低的，只是把不可能變成了可能（從這一點上來說，技術才是業務的enabler）。然後就會有提高效率的需求出現，要求改進這個技術。這個技術的低效率部分就會被其他人（或者技術發明人自己）加以改進，這部分就會形成新的技術。
架構師應該承擔起解決業務問題的這個角色來，專注於business domain和軟體本身的架構，讓技術人員致力於為業務在計算機中跑起來而努力。只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。最終一定會得到乙個很好的軟體架構，令軟體開發團隊和業務部門都能夠很好地開展工作並降低成本。
讀漫談架構
六 軟體架構到底要解決什麼問題？要解決誰的問題？軟體實際上就是把現實生活模擬到計算機中，並且軟體是需要在計算機的硬體中執行起來的。需要解決的問題 一 業務問題 具體的現實生活狀態中，沒有軟體的時候，所解決的問題的主題是誰，解決的是什麼問題，是如何解決，如何運作的？二 計算機問題 1.如何模擬？2.硬...
《架構漫談》摘要
一 architecture is like teenage everybody talks about it,nobody really knows what is it.architecture is both the process and the product of planning,de...
重讀《架構漫談》
一直以來，在軟體行業，對於什麼是架構，都有很多的爭論，每個人都有自己的理解。甚至於很多架構師一說架構，就開始談論什麼應用架構 硬體架構 資料架構等等。我曾經也到處尋找過架構的定義，請教過很多人，結果發現，沒有大家都認可的定義。套用一句關於big data流行的笑話，放在架構上也適用 architec...