架構圖:
1.依賴調用關系.(類似文獻引用關系, graphviz 自動將每一次調用升一次層級)
2.依賴調用可能是上下層級調用,也可能是同層級引用. 需人工去梳理出這些關系
3. 引用多的用顏色標識出來
4. 讀來寫,讀來透傳(phoenix), 讀來組合(加上 uid 的帳戶層) ,讀來通知(支付模塊)
產品考慮的是以人為對象的算法.
架構師要考慮各個細節流程內部的算法. 比如分潤規則的 n 個規則匹配,用策略模式.
5. 架構的另外一個本質是封裝變和不變. 變的東西有幾個層面: 1.抽象為業務字段,用 for,if 能解決業務的可變性. 變量能否解決,type 能否解決,type 接口類能否解決 2.配置能否解決 3. 終極,業務可變性實在太大,變量是代碼.
舉例: dd 平台化: 中台是引擎層. 內部有各個流程,層級(訂單,支付). 各個業務線也有自己的層級(訂單,支付). 業務線的支付依賴於業務線訂單,同引擎層.
直接畫圖,結果是這樣的: 
這張圖將業務線訂單和引擎支付放在同一個層級了. 錯誤,凌亂.
正確的層次+依賴圖:
改進,子圖排版(2007-06-22 https://stackoverflow.com/questions/12463541/subgraph-layout-in-graphviz The following was achieved by using invisible edges and constraint=false on some edges:
https://stackoverflow.com/questions/8002352/how-to-control-subgraphs-layout-in-dot)
被表結構誤導: 本來以為業務層只有 trade 相關邏輯. (因為表上只有 trade 表 是分為 代保 和 普通代) . 業務層的流程和引擎層是相同的.
這是更復雜的垂直業務切分案例.
第一份工作: 最簡單的垂直業務切分.
第二份工作: 水平切分.(訂單域,支付域,營銷域) 大流程;
第二份工作中期: 1. 模塊內流程切分.(trade,賬單,支付,分潤,流水,發票) 2. 表結構的拆分.(帳戶系統誕生) 邊界(網關系統誕生) 將字段抽象為存儲,更通用.
第二份工作后期: 含引擎的垂直切分.(訂單域,支付域) 借鑒 1.企業支付(含整個流程的獨立支付域) 2.平台上的中台策略
舉例2: phoenix 支付. 統一了所有支付到一個接口. 大部分都是相同的.不同的東西都通過 map 來傳遞. 更通用是通過 josn+泛化調用. 其他業務字段定義合理也很關鍵. 有時候1對多關系變更了,一切都變了.
中間插入最好插入到業務上游(生命周期上游)
高級應用 寫代碼,編程繪制架構圖(分層拓撲圖)
1. 子圖,子圖連接,子圖里包含子圖. 邊界線 虛線? graph[style=dotted];https://stackoverflow.com/questions/8366314/drawing-a-border-around-a-set-of-vertices-in-graphviz
2. 布局控制 相同子圖下的節點保持水平(http://graphs.grevian.org/example). 子圖aligning 對齊 :constraint=false 強制排序節點. http://www.graphviz.org/content/aligning-subgraphs
3. 排版控制 默認排版原則,按箭頭有序. 定制有序: rank = same; 子圖不是整體. 不能以子圖排版. (需要更牛逼的自適應排版,有交互有層級的拓撲圖)
4. 代碼變量驅動. 4.1 可以只改變某個參數. 4.2 可改變節點名. [詳細見附件]
多看看http://www.graphviz.org/forums/general-discussion 和 stackoverflow 上的關於 graphviz 的問題.
base on graphviz
附件:
代碼變量驅動:
digraph G {
a -> c[label="123",color=red];
a -> b;
b -> c [label="1235",constraint=false];
b[label=c]; //只改節點名
c[label=b];
a -> c[lable="234"]; //只改 lable.
}