摘自
https://segmentfault.com/a/1190000021887191
https://segmentfault.com/a/1190000022122201
限界上下文（Bounded Context）
系統(tǒng)內(nèi)部按照不同業(yè)務(wù)目的進(jìn)行劃分的「模塊」
BC的劃分
需要架構(gòu)師有著豐富的行業(yè)知識(shí)或者需要一個(gè)有些系統(tǒng)分析經(jīng)驗(yàn)的業(yè)務(wù)分析人員
一種可行的方法就是參考敏捷的實(shí)踐
先劃分一個(gè)粗略的 BC 模型；
然后在每個(gè)迭代中細(xì)化；
不斷的明確每個(gè)領(lǐng)域?qū)ο蟮穆氊?zé)愿伴；
提煉業(yè)務(wù)規(guī)則背后的模型。
通過 code review 和迭代后的會(huì)議分析現(xiàn)有 BC 的合理性并加以修改
需要類似 CI添瓷，單元測試等其他敏捷實(shí)踐的支持，才能保證模型的不斷演進(jìn)
BC的實(shí)現(xiàn)
-
結(jié)構(gòu)
image.png - BC間Anticorruption Layer(防腐層) 模式
對(duì)外提供基于 Facade 模式的粗粒度接口
通過 Adapter 將輸入的數(shù)據(jù)適配為 BC 內(nèi)部服務(wù)所需的數(shù)據(jù)對(duì)象 - 具有相同名稱的領(lǐng)域?qū)ο笤诓煌?BC 中的實(shí)現(xiàn)
一方面需要通過「統(tǒng)一語言」這一模式值纱，在團(tuán)隊(duì)內(nèi)部(不僅僅是研發(fā)團(tuán)隊(duì)鳞贷，還應(yīng)該包括業(yè)務(wù)分析團(tuán)隊(duì)和使用系統(tǒng)的業(yè)務(wù)部門)統(tǒng)一對(duì)于這兩個(gè)不同領(lǐng)域?qū)ο蟮睦斫猓苊馄缌x
另一方面虐唠，更好的做法是給這兩個(gè)領(lǐng)域?qū)ο蟾髯云鹨粋€(gè)更為恰當(dāng)?shù)拿Q搀愧，例如 在在「新契約」與「理賠」這兩個(gè)不同的 BC 中的「保單」，分為IssuedPolicy 與 ClaimPolicy疆偿，幫助團(tuán)隊(duì)加深理解妈橄。
CQRS
Command Query Responsibility Segregation
核心思想
將「命令」（對(duì)會(huì)引起數(shù)據(jù)發(fā)生變化操作的總稱）與「查詢」（不會(huì)對(duì)數(shù)據(jù)產(chǎn)生變化，只是按照某些條件查找數(shù)據(jù)的操作）的操作進(jìn)行分離翁脆，然后在兩個(gè)獨(dú)立的「服務(wù)」（一般是指兩個(gè)獨(dú)立部署的應(yīng)用眷蚓。在某些特殊情況下，也可以部署在同一個(gè)應(yīng)用內(nèi)的不同接口上）中實(shí)現(xiàn)
架構(gòu)圖
挑戰(zhàn)
基礎(chǔ)設(shè)施
可靠的消息中間件
分布式事務(wù)中間件
不同類型的數(shù)據(jù)存儲(chǔ)引擎【比較常見的情況是 Command 端依然使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫反番，但是對(duì)于那些比較特殊的查詢則使用專門的數(shù)據(jù)存儲(chǔ)】技術(shù)能力
對(duì)于事件的支持的設(shè)計(jì)
查詢模型的設(shè)計(jì)【依然需要使用領(lǐng)域驅(qū)動(dòng)的思路設(shè)計(jì)查詢接口】
事務(wù)【根本來說是數(shù)據(jù)的最終一致性問題】
