Building Evolutionary Architectures : Support Constant Change 心得歸納4
沒錯,我跳過CH.4架構耦合,裡面還描述了ESB等SOA,金融業我碰太多了
甚至還看過原廠做的巴克球電文(極複雜難以拆解的電文流程)
回到本章(CH.5),開頭有推薦另一本可參考的專門書籍:
Refactoring Databases: Evolutionary Database Design(Scott J Ambler, Pramod J. Sadalage)
可演進的資料庫設計
- 資料庫schema事抽象的,與類別階層很像.
- 隨著底層的情況發生變化,抽象開發者與DBA必須反映那些變化
演進schema
- 設計可演進資料庫的關鍵是讓schema隨著程式碼一起演進
共享資料庫整合
- 常用的重構模式可處理這些耦合,稱為擴展/合約(expand/contract)
- 以下簡單描述書上範例順序:
- Customer表格剛開始有CustomerID與Name欄位
- Customer表格擴展增加Firstname與Lastname欄位(內容就是Name欄位拆解)
- Customer表格合約移除Name欄位(因為已經有足夠欄位可以說明描述Name)
不恰當的資料耦合
兩階段提交交易
- 架構師有時候會錯誤地試圖建立一個粒度比商務的正常粒度要小的架構
- 如微服務架構不太適合重度交易系統,因為目標服務量子非常小
- 服務式(我猜是要說SOA)架構往往有更好的表現,因為它有較寬鬆的量子大小需求
- 當你將單體架構風格轉換成粒度更細的架構風格時,應該先從少量的大型服務開始著手,盡力限制服務與資料背景的大小
資料的年齡與品質
- 常有CTO說"我不太關心應用程式,因為它們的生命週期很短,但是資料schema非常寶貴,因為它們是永恆的"
- 但是資料庫schema仍然是現實世界的抽象,而現實世界會隨著時間變化,那麼相信schema勇永不變的DBA忽略了這個事實!
- 如果DBA從不重構資料庫與變更schema,他們是怎樣進行更改來適應新抽象?
- 後面案例分享有提到 →當架構師建立演進式架構時,必須把資料是為主要的關注點
個人心得:
軟體開發離不開資料,社群分享上面部分時也有人提到SP
我個人會覺得SP可能也是視資料庫schema為永恆的一種體現
因為SP的調整非常困難,甚至很少有人會考慮調整SP
而SP牽扯關聯的schema若異動了,也會造成SP出現錯誤(而且很難debug)
畢竟資料庫的主要目的就是資料的庫
不是拿來將資料加工產出商業價值的軟體
