六邊形架構(hexagonal architecture):目的是將輸入輸出放到設計的邊緣.應用獨立化,業務邏輯不依賴暴露rest或graphql api,資料**可以是具體的資料庫,外部微服務api,甚至乙個檔案.
主要是為了解決物件導向開發中,由於分層造成業務邏輯在不同層間耦合的問題.這個模式允許應用核心邏輯隔離外部系統.以實現核心邏輯修改不影響外部服務.
實際架構是以業務邏輯為核心,外層是資料來源和傳輸層.
業務邏輯三個核心概念:
實體(entities):是域物件(domain objects).不關心實際儲存.
庫(repositories):負責與資料來源互動和進行實體操作的介面.
互動器(interactors):負責規劃和執行域行為.可看作服務物件或使用者例項物件.用於實現複雜的業務規則和校驗域行為具體邏輯.
通過上面三個核心概念,定義業務邏輯時就不需要關心任何資料儲存和業務邏輯觸發的問題.因為具體儲存使用實現儲存介面的儲存源;業務邏輯觸發是外部服務主動請求.
業務邏輯之外是資料來源(data sources)和傳輸層(transport layer):
資料來源:適配不同的儲存實現.實現業務邏輯和資料實現解耦
傳輸層:觸發互動器去執行業務邏輯.將其看作業務系統的輸入.常用的傳輸層是http api層和一系列處理請求的控制器.通過抽取業務邏輯到互動器,解耦特定傳輸層或控制器實現.互動器被觸發不僅可以通過控制器,還可以是時間,定時任務,命令列等;
傳統的層級架構,是上層直接依賴下層.而六邊形架構中所有依賴全部在內部,核心業務邏輯不關心實際的傳輸層和資料來源.但是,傳輸層知道如何使用互動器,資料來源知道如何遵守庫介面.
由於資料來源和業務邏輯解耦,我們只要實現庫介面定義,就能輕易的變更資料來源實現.
參考資料:
ready for changes with hexagonal architecture
SOA RPC REST 和六邊形架構
ddd 的一大好處就是並不需要使用特定的架構，經典分層架構只是一種，由於核心域位於限界上下文中，我們可以使用多種風格的架構，既然如此，我們應該把眼界看的更寬廣些，有意思的東西多著呢。soa 和 rest 這兩個貨，我們都比較熟悉，他倆並不是由 ddd 引入，但卻可以適用於 ddd。我個人覺得，要想把...
六邊形平面
現在有乙個n n的六邊形網格平面 這種平面類似蜂窩形狀 下圖是n 1,2,3,4條件下的具體形狀，根據它們可以依次類推n 5,6,現在你需要對n n網格中一些格仔進行上色，在給定的輸入中這些格仔被標記上字元 x 而不用上色的網格被標記為 上色時需要注意，如果兩個被上色的格仔有公共邊，那麼這兩個格仔需...
2701 六邊形點陣
題目描述 description 輸入六邊形的邊長n，請你畫出這個六邊形點陣。輸入描述 input description 僅一行，乙個整數n 輸出描述 output description 六邊形點陣 有兩條邊水平 樣例輸入 sample input 6 樣例輸出 sample output 資料...