iT邦幫忙

2021 iThome 鐵人賽

DAY 3
0
Software Development

淺談中台架構、DDD與Python實踐系列 第 6

【Day 06】領域驅動設計的戰略設計(Strategic Design)

前言

我們常會使用業務性質來界定領域範圍(Bounded Context),例如,採購、銷售、庫存、運輸、會計...等,一般而言,這並沒有問題,但是,回到中台架構的理念,我們希望透過共享架構的建立,達到復用(Reuse)的能力,因此,以業務性質界定領域範圍後,應該進一步進行水平整合,將共有的功能獨立出來,才能建構共享、復用的平台。

子領域的切割

企業資源有限,開發團隊可能無法在短時間內滿足所有業務需求,因此,必須把領域範圍區分為核心域(Core domain)、支撐域(Supporting domain)及通用域(Generic domain),然後把焦點集中在核心域,創造競爭優勢,支撐域可以外購或外包,配合公司業務的快速發展,例如,餐飲業可以把外送業務直接委託FoodPanda、Uber...等外送平台,至於通用域就必須慎重考慮,例如,權限控管機制關係到單一登入(Single Sign-On, SSO)的重大決策,又客戶管理領域牽涉到各部門,如何方便共享並兼顧隱私權的維護,不管是外購或自建,都必須考慮到戰略資訊系統的長遠規劃。以產物保險系統為例,可以作以下的切割:
https://ithelp.ithome.com.tw/upload/images/20210925/20001976MnnVrtq23z.png
圖一. 產物保險系統子領域的切割

外部系統的界定

DDD 使用 Context Map 界定與外部系統的關聯,DDD發明人Eric Evans將關聯按控制(Control)與通訊(Communication)的依存度分為九種,如下圖:
https://ithelp.ithome.com.tw/upload/images/20210925/20001976CjwDZUB3Xh.png
圖二. 系統關聯的類型,圖片來源:Domain-Driven Design: Strategic Patterns

九種關聯模式說明如下:

  1. 單一領域範圍(Bounded Context):兩個系統同在一個領域範圍,密不可分。
  2. 共享核心(Shared Kernel):兩個系統共享一份領域模型,甚至也共享程式碼,應該是指函數庫(Library)。
  3. 客戶與供應商的關係(Customer/Supplier):上下游的關聯,上游系統供應資料給下游系統,必須注意承諾與時程(commitment and schedule),例如物聯網須定時傳輸感測資料給資料中心。
  4. 遵奉者(Conformist):上游系統沒有強烈動機要提供資料給下游系統,萬一上游系統不準時傳送資料,下游系統就會很慘,除非它有備案。
  5. 防腐層(Anti-Corruption Layer):下游系統建立一層翻譯層(Translation layer),負責上、下游間的資料轉換,以避免上游系統的修改。
  6. 開放主機服務(Open Host Service):上游系統定義通訊協定,提供資料交換,例如透過RPC(Remote Procedure Call),外部系統就可以存取主機的各項資源。
  7. 事件出版者(Event Publisher):提供出版/訂閱模式,進行資料交換。
  8. 出版語言(Published Language):提供共通的文件格式,例如XML、JSON、Protocol Buffers。
  9. 各行其事(Separate Ways):兩個系統無明顯關聯。

區分這些模式有點政治化,可能因一方比較強勢,就會決定使兩個系統的關聯模式要採用那一種,不管如何,一但決定了,後續架構及設計就需因應發展。

Eric Evans特別提到舊系統的汰換,不要想一步淘汰舊系統,可以利用防腐層模式接通舊系統,再逐步利用新技術,將舊系統的功能一塊一塊替換掉,這是一個好主意,可以降低風險。

架構分層

為了程式容易擴充與維護,通常我們會對系統架構進行分層,不論是 Client/Server、N-Tier、MVC/MVVM...等,都是將程式的使用者介面(UI)、業務邏輯及資料庫存取分離,避免單一檔案過大,且混在一起很難修改,DDD也不例外,將架構分為四層,如下圖:
https://ithelp.ithome.com.tw/upload/images/20210926/200019764220e6wQyB.png
圖三. DDD分層架構,圖片來源:Implementing Domain-Driven Design

DDD將中間層分為應用層(Application Layer)及領域層(Domain Layer),領域層包裹領域模型,並將相關業務邏輯涵蓋在內,應用層只是薄薄一層,組合相關領域模型,負責安全認證、發送通知、...等事務。另外,DDD強調設計模式(Design Pattern),例如依賴注入(Dependency Injection, DI)可反轉圖三架構,以宣告式方式產生物件,或是Repository Pattern結合工廠模式(Factory Pattern),可統合一般物件的新增、更新、刪除、查詢等共通功能,避免每個類別重複撰寫類似的程式碼。

完整的架構可參考下圖:
https://ithelp.ithome.com.tw/upload/images/20210926/20001976czpkOBcIT3.png
圖四. 詳細的DDD分層架構,圖片來源:一文解析DDD中台和微服务设计

結語

由上介紹,戰略設計(Strategic Design)相當於架構規劃,良好的規劃是專案成功的第一步,規劃的初衷永遠不要忘記:

  1. 聚焦核心域的開發。
  2. 共享與復用。

不要以職場政治為唯一考量。


上一篇
【Day 05】領域驅動設計的啟動
下一篇
【Day 07】領域驅動設計的戰術設計(Tactical Design)
系列文
淺談中台架構、DDD與Python實踐7

尚未有邦友留言

立即登入留言