這兩天準備要接手天津商行的專案。但是在接手的過程中，對整個專案的理解卻是非常的困難。最大的問題，就是對業務的不理解。
天津商行的這個專案不大，核心的業務就是日結，及其圍繞在日結之周圍的一些相關業務。其實也並不是特別的複雜，但是轉來轉去，開賬閉賬，憑證科目什麼的，的確對乙個財務的門外漢是異常的頭痛。雖然有還算明細的需求文件，但這些需求更多表述的是業務的表現，而對於業務過程和相關的知識卻沒有什麼描述。
業務上的不理解，也就造成了即使看**也沒有多大的幫助，更何況**的質量也不甚良好。**大多都是平鋪直敘的**，如果單就乙個方法（業務方法）而言，理解起來還算是很容易的。可是問題是，這類裡足足有七十多個這樣的業務方法，沒有分類，注釋也只有簡單的描述，如果你不理解業務，那這就是噩夢，根本不知道從何下手。這樣的類大概有二十多個，純粹的描述業務的類，極度鬱悶。
對於技術、業務還有架構，常常會有各種各樣的疑惑，但更多的就是究竟要更側重那乙個方面，也就是所謂的魯棒性了。
目前，社群內對於技術還有架構討論的是有模有樣的，但是真正能符合這些複雜業務的開發嗎？或者說用這些熱門的東西，來實現我的這些業務，真的能達到易於擴充套件易於維護嗎？
有沒有討論這些業務的社群呢？大家都在更關心架構等純技術的東西，可實際應用中，難道不是業務才是公司的利潤之本麼？
也許，就沒有真正正確的答案。
細品架構9 100 技術 業務和架構之間的關係
在軟體設計開發的過程中經常會看到，很多所謂的架構討論實際上只是在討論某種技術。在很多人的概念裡面，架構和技術實際上是等同的。學會了幾種技術，就認為自己是架構師了，甚至是學習的技術越多，就覺得自己的水平越高。這樣實際上是對自己很不負責任的。要知道任何技術都是為了解決某種問題而存在的，學會了技術，並不代...
業務和技術的融合
我記得三年前去一家軟體公司應聘的時候，面試我的是乙個做市場方面的領導，當時他問了我乙個問題 你認為技術是最重要的嗎，業務一點都不重要嗎？聽他這麼問，我當時就說不是，業務也很重要，技術要依託於業務才能產生價值。來到現在幹的這家公司後，前些天又聽到我公司的技術總監說 其實單純做技術是走不遠的，技術要和業...
業務架構 資訊架構 技術架構三位一體
客戶天天打 要修改產品功能，簡單的乙個需求可能要做乙個月。產品越改越笨重，為了趕工期bug越來越多。頭疼！產品從初級版到現在已經四個年頭，相關的程式設計師來去換了三批，在補丁上打補丁是常有的事，很多功能只是開了個頭，換個專案經理就被遺忘。我們總是害怕客戶在這個產品上提出新的需求，只要客戶還用得過去，...