Chapter 24 - 部分邊界

全面性的架構邊界代價是昂貴的，在設計上也會因為預想某個地方可能需要一個邊界，而預先的為這個邊界保留一個位置，但這樣子的設計違反了YAGNI原則(You Aren’t Going to Need it 你還不需要他)，這種情況下，我們就會需要部分邊界(partial boundary)

三種可行的簡單方式

跳過最後一步

完成可獨立編譯及可獨立部署元件所需的所有工作，然後將它們全部包在同一個元件裡面。(簡單的說就是我全都要)

如此一來，雙方能受惠的介面包含在裡面，輸入輸出會用到的資料結構也在裡面，但我們將他們全部都編譯和部署成一個單一的元件了。

Strategy Pattern 策略模式


ServiceBoundary介面由Client使用，並由ServiceImpl實作。

原本的依賴方向是虛線箭頭，而我們加了介面跟制定了邊界，為了未來的架構邊界訂定了基礎。


來看一個策略模式的UML

  • CashNormal - 普通收費
  • CashRebate - 打折收費
  • CashReturn - 紅利收費
  • CashSuper - 抽象收費策略
  • CashContext - Client

我們在CashSuper抽象策略中訂定了收費方法，然後讓各種收費去實作具體的收費方法細節，Client再選擇要使用的方法去套用。(一種我要達成同一個目的有很多’策略’可以實行的感覺)而此處的CashSuper就像是書內所說的部分邊界。

Facade Pattern 外觀模式


外觀模式，為子系統的一組介面提供一個一致的對外介面(高層介面)，使得子系統的使用更加容易。


或是像上圖對於子系統的封裝，可以由原本的雜亂依賴，依靠一個Facade去將子系統與使用子系統的Client分離出來，以達成減少耦合性的功用。