WechatIMG341521705278_.pic_hd.jpg
這張圖是2008年的銀行信用卡的ER圖，目前可以看到這圖，圖中的Entity的條目非常滿當，非常擁擠，每一個Entity以及ValueObject由大量的屬性構成。
WechatIMG351521705279_.pic_hd.jpg
到了2012年，當時的股票交易系統SOA(service oriented architecture)的架構，此時系統構圖看著還是比較簡潔的一種，但是到了后面就如下圖所示了
WechatIMG361521705279_.pic_hd.jpg
2016年的股票交易系統，就變得異常的復雜了，想維護起來都是異常困難。
WechatIMG371521705280_.pic_hd.jpg
到了2018年，此時的保險項目的微服務架構形成了目前的形式。從上至下分別為
API service， composition service， 以及core service ，從上至下，相當于從infrastructor慢慢形成組成API service，然后再有不同的API，組成相應的核心服務。
WechatIMG381521705280_.pic_hd.jpg
這樣的架構屬于數據驅動架構，這樣做的目的主要是作為解耦。對于圖中間的ESB，在之前的設計中可以理解為路由，比如一個請求入到ESB中，ESB會根據相應的數據，將請求導向相應的位置中去，圖中左側的web可以理解為每一個模塊，這樣一套ESB系統的投入差不多在千萬級別左右，這樣的系統適合用于分布式系統中，一般設置這種系統的規模，人數應該在400-500人左右才會設置這樣的系統。
于此同時，在結合上面幾個圖，開始時候很簡潔明了，到后面的及其復雜，因此我們考慮架構的時候應該把時間因素結合進去。
WechatIMG391521705281_.pic_hd.jpg
我們在架構的時候會遇到的問題
WechatIMG401521705282_.pic_hd.jpg
如何解決這個問題？
圖中左側的STORIES，可以理解為統一語言，在統一語言的基礎的進行拆分，但是問題也隨之出現，隨著左側的拆分，拆分粒度越細小，系統設計得越爛。
理想的架構思想應該是和進化論一樣，隨時時間的推移而進行演變，也就引導了下一步：適應度方程(Fitness Function)。
WechatIMG411521705282_.pic_hd.jpg
在圖中，右側的色彩塊，每一個像素都代表著一種顏色，要讓右邊無規則的色彩慢慢演化成蒙娜麗莎這幅畫，每一個色彩像素都會自動進行調整，往著蒙娜麗莎進行演化，這就是大致的適應度方程的介紹。更多關于適應度方程的介紹，可以上youtube。
WechatIMG421521705283_.pic_hd.jpg
架構與組織共同進化，這里的核心詞是支撐域，核心域。一個團隊的支撐域可能就是另一個團隊的核心域，每一個團隊最核心的任務就是找到屬于自身的核心域。
WechatIMG431521705303_.pic.jpg
image.png
怎樣適應進化論？使得架構更具生命力？Evan Bottcher提出一下概念，也就是這個圓形圖案，要堅持四個原則
fast feedback
repeatability
simplicity
clean code
于此同時必須考慮到時間維度，將時間的考量納入系統架構設計中。
并不是在業務領域的絕對正確以及規范就是代表著架構的正確。
同時在分解業務的時候，必須找到團隊自身的核心域。
如何找到屬于自己團隊的核心域，這個得根據clients來具體分析，但是一定要關注時間維度。
WechatIMG441521705303_.pic.jpg
WechatIMG451521705303_.pic.jpg
在現在的DDD中，一般情況是業務和系統捆綁在一起(??有點不理解這句話)。
WechatIMG461521705303_.pic.jpg
一般業務怎么落地？ 通常而言，對于目前情況，有兩點
-
common language
WechatIMG511521705304_.pic.jpg boundary context
DDD構建快，建模快，但是不能盲目用在無限大的領域上。
根據梳理過后的需求，抽離出領域模型
一下均為實驗項目
WechatIMG471521705303_.pic.jpg
WechatIMG491521705304_.pic.jpg
WechatIMG501521705304_.pic.jpg
WechatIMG511521705304_.pic.jpg
WechatIMG521521705314_.pic.jpg
WechatIMG531521705314_.pic.jpg
