最近工作重點轉移到了SAP Commerce上來,正好有機會把該産品裡由Java實作的訂單處理架構和我之前長期工作過的,ABAP實作的SAP CRM One Order架構做個比較:基于Spring的Bean替換機制 vs ABAP函數+配置表,兩種方式都實作了強大的可擴充性。
SAP Commerce的訂單處理架構把訂單處理業務按照步驟拆分成一個個細粒度的處理單元,封裝到一個個Spring Bean裡。模型和其行為之間通過政策模式(Strategy Design Pattern)進行松耦合式的關聯。Commerce二次開發人員可以靈活地将定制業務邏輯實作在自開發的Bean裡,并将其通過Spring架構注入到Commerce的訂單處理架構中,實作訂單處理業務的定制效果。
而SAP CRM One Order裡一系列維護在配置表裡的函數,學習了SAP Commerce之後,我傾向于把它們類比為比SAP Commerce Order Bean更細粒度的處理單元。SAP Commerce裡能夠注入的Order處理邏輯的粒度是一個端到端的操作,比如SubmitOrderStrategy,CloneAbstractOrderStrategy,CreateOrderFromCartStrategy, SaveAbstractOrderStrategy, 一個Bean就能實作一個端到端的Order操作;而SAP CRM One Order架構配置表裡可以靈活配置的ABAP函數,往往需要多個函數組合在一起協同工作才能完成一個上述操作。雖然可配置和替換的粒度不同,但都殊途同歸:在不修改SAP标準代碼的前提下,給二次開發人員提供一種靈活的增強機制(Extensibility).
本文來自雲栖社群合作夥伴“汪子熙”,了解相關資訊可以關注微信公衆号"汪子熙"。