原创 匹配神器Hamcrest 認識Hamcrest 內置的匹配器 Hamcrest的結構

認識HamcrestHamcrest是一個匹配工具,提供了常用的匹配的工具方法,主要在自動化測試匹配場景中使用,不過也可以用在其他場景下。下面是判斷兩個對象是否相等(如果是數組,則數組裏面的元素需要全部相等並且順序相同)的一個例子。再看一個

原创 系統架構中的拆分與集成

引言 有一個認可度比較高的對於軟件系統架構的定義:職責明確的模塊或者組件、關聯關係、約束和指導原則。如下圖所示:當我們通過需求分析得到了業務的實例化規則以及領域模型之後,接下來就是進行系統的架構,按照上面對架構的定義,其中比較重要的步驟就是

原创 用例分析建模

用例分析是一種簡單方便的建模方法,基本過程是根據已有的用例進行分析,找到領域的模型類、屬性以及模型之間的關聯關係。因此,通過這種方式建模主要輸入爲用例。完整的用例編寫需要耗費大量的時間,而且需要專業的培訓,在現實的工作中我還從來沒見過哪個項

原创 需求分析之實例化需求

引言之前在看一些需求建模的文章或者書籍時,常常看到用例分析法,根據用例裏的主謂賓來構建模型、模型的方法以及模型之間的關係等。但是在工作中遇到的一個問題是拿到的需求往往只有一份PRD,只是對於需求的功能進行了簡單的描敘,那如何才能對PRD或者

原创 電票的腐化過程

電票是17年上線的一個項目,主要功能比較簡單,由兩個主要部分組成,一個是電票的支付單,一個是電票,功能列表如下。開發過程數據表項目按照以往的經驗,先設計需要的表結構,其中包括支付單關聯以及電票、電票請求三張表(參考了之前類似項目的經驗),並

原创 事務腳本與領域模型

最近看了下《企業應用架構模式》,裏面提到了事務腳本跟領域模型兩種建模方式,作者比較推崇領域模型,認爲在複雜業務下面可擴展與可維護性更好。但是在實際工作中其實並沒有特別的體會,並且之前一直使用的都是類似事務腳本的方式,比較簡單易懂,不需要太多

原创 系統的穩定性監控

前言在系統上線之後,或多或少總是會存在問題,有機器性能方面的問題,例如CPU Load過高,內存使用率高,RT高,線程池滿,FullGC之類,也有業務邏輯的問題,例如支付系統中金額計算錯誤,狀態校驗錯誤等。爲了儘量減少線上的影響(對用戶造成

原创 一行改動半小時

今天工作中遇到一個問題,在支付成功回調時支付系統中校驗金額報錯,需要在校驗金額時給定一個參數,做一下轉換,核心邏輯一共只有幾行,但是修改了半個多小時,主要時間花費在以下幾點。首先是參數模型需要定義多套,系統的框架採用的是插件方式,如果涉及到

原创 淺談應用架構

前言去年11月從之前的業務部門調動到業務平臺之後,團隊的重心與目標都發生了不少的變化,之前的團隊主要服務一個業務方,業務的目標相對比較重要,對於技術人員的業務sense,產品sense要求比較高,會要求從業務發展與規劃方面入手對技術進行佈局

原创 複用之艱

最近幾年,中臺之風盛行,各行各業都希望能建設自己的”大中臺,小前臺“,期望能夠通過強大中臺的複用能力快速的賦能業務,讓新業務可以快速試錯,降低整體成本,但是實踐下來發現困難重重。剛好最近在參與一個跨域功能點的複用開發,藉此梳理下軟件架構中複

原创 淺談方法論

不知道大家有沒有遇到過下面的一些情況 1. 例如在管理項目的過程總是遇到類似的問題,例如時間評估不準確,資源不到位等 2. 看完的書過一段時間就不太記得,好像沒看過似的,感覺沒什麼收貨 3. 對於解決過的問題下次遇到又要回過頭去看看上次的方

原创 淺談成長性思維

前段時間看了《終生成長》這本書,趁着還沒有完全忘記之前對一些感受總結一下。《終生成長》主要介紹與論證成長性思維的重要性,跟《刻意練習》比較類似,兩本書對於天賦與學習對於個人可以取得的成就的影響觀點比較類似。通過這本書對我比較有觸動的是個人能

原创 一種架構實踐:自上而下的分解與自下而上的抽象

這種方法是內網中的一篇文章,我覺得很有實踐意義,就利用自己的理解重新梳理一下。當我們拿到一個需求,從小需求到項目再到新系統的搭建,應該都是有一套方法論可以指導落地。如果按照DDD的方式來落地架構的話,一般系統可以分成三層,從內到外分別是領域

原创 常見方法論

解決問題三部曲按照結構化思維,可以將解決問題劃分爲三步:定義問題,分解問題,歸類分組。定義問題:當前現狀如何,目標是什麼分解問題:達成目標的步驟,任務是什麼樣的SMARTSpecific - 具體的; Measurable - 可衡量的;A

原创 代碼工匠XMIND