????????軟件系統(tǒng)從單體應(yīng)用到多系統(tǒng)應(yīng)用（水平拆分、垂直拆分）的架構(gòu)演進(jìn)方式，相信已經(jīng)深入人心。服務(wù)化，高內(nèi)聚低耦合。但是，經(jīng)常發(fā)現(xiàn)，這些拆分之后的兄弟應(yīng)用讀取DB還是會(huì)存在藕斷絲連的現(xiàn)象，沒(méi)完全拆分干凈。

示例如下：

?

?

之所有出現(xiàn)這種現(xiàn)象，推測(cè)有幾個(gè)方面的原因

1 認(rèn)為不要緊，不用拘泥于一些約束，直接寫(xiě)DAO操作DB反而效率更高，更靈活

2?項(xiàng)目開(kāi)發(fā)時(shí)間壓力較大，為快速實(shí)現(xiàn)，直接讀寫(xiě)DB

3 數(shù)據(jù)庫(kù)表歸屬不清晰，多個(gè)應(yīng)用都有歸屬

????????最近在梳理這邊應(yīng)用域的系統(tǒng)問(wèn)題時(shí)，發(fā)現(xiàn)也存在這種現(xiàn)象，同一個(gè)DB多個(gè)應(yīng)用都在讀寫(xiě)。同時(shí)也在思考這個(gè)問(wèn)題，我們到底要不要堅(jiān)守這個(gè)原則。某應(yīng)用域下的DB，只能該應(yīng)用可讀寫(xiě)。

????????無(wú)規(guī)矩難成方圓，系統(tǒng)架構(gòu)是有約定的。合理的約定需要遵守，否則，被動(dòng)或者主動(dòng)的違犯會(huì)對(duì)現(xiàn)有架構(gòu)進(jìn)行腐蝕，時(shí)間一長(zhǎng)，難以維護(hù)。表面上看應(yīng)用直接讀取歸屬其他應(yīng)用的DB，開(kāi)發(fā)效率會(huì)高些，但是一來(lái)你已經(jīng)在腐蝕現(xiàn)有架構(gòu)，再則之后你需要感知非你應(yīng)用域下的數(shù)據(jù)庫(kù)模型變更，同時(shí)其他應(yīng)用域模型變更需要通知到你，為已經(jīng)拆分的解耦應(yīng)用間添加了一個(gè)新的強(qiáng)耦合。之前我遇到過(guò)一個(gè)系統(tǒng)，把dao層的代碼通過(guò)jar包共享出來(lái)了，解決重復(fù)編寫(xiě)dao代碼的問(wèn)題，但是每次數(shù)據(jù)模型有變更，都需要評(píng)估本應(yīng)用和兄弟應(yīng)用的影響面，非常難受。

????????軟件架構(gòu)和開(kāi)發(fā)都講求分層，數(shù)據(jù)模型處理是由相關(guān)歸屬應(yīng)用來(lái)負(fù)責(zé)的，包括整個(gè)模型生命周期的完整、緩存的管理和對(duì)外服務(wù)提供的完整等。其他非模型歸屬的應(yīng)用，如果涉及到這塊業(yè)務(wù)，關(guān)心的是服務(wù)的使用，不用涉及到底層Manager和DAO的細(xì)節(jié)實(shí)現(xiàn)。其實(shí)這也是一種分層，數(shù)據(jù)模型處理層和模型服務(wù)使用層，底層模型處理和上層模型服務(wù)使用層解耦，兩者通過(guò)服務(wù)接口協(xié)議交互。上下層都遵循這份接口協(xié)議，自行在各自的分層下迭代改進(jìn)，容易擴(kuò)展。?如下圖示例

?