作為一個后端程序員，MVC三層架構的模式相信大家都不會陌生，三層分別從上而下排布，只能由上層調用下層。一般越往下層越通用，越上層越細節。
隨著某些核心業務的訪問量發展，通常我們需要去進行優化的措施，比如加緩存，加MQ，換數據源
1.緩存可選redis，memcache 2.MQ可選kafka，rocketmq，rabbitmq 3.數據源可選：MySQL，mongodb，elasticsearch 復制代碼
當然，我們在做這些優化的時候，會將mq,mongodb等看成基礎設施層。 由此衍生出四層的架構，infrastructure里封裝redis和mq的通用調用邏輯
這些優化的動作，通常不會改變原有的業務邏輯。但是為了做優化，我們會將它寫在service層，比如：
1.執行成功就發個MQ 2.執行某個事件的時候，同步一下緩存 3.依賴關系為，domain依賴infrastructure
問題點：
按道理來說，domain層是寫業務邏輯的，優化不會涉及到業務邏輯的改動，但是卻改動了domain層。由于domain層依賴了infrastucture的原因，導致業務依賴于具體的實現技術。所以，為了將業務與具體實現做分離，我們采用依賴倒置的手段去重構
依賴倒置原則的包含如下的三層含義： 1.高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象 2.抽象不應該依賴細節 3.細節應該依賴抽象
高層模塊不依賴低層模塊：那就可以在domain層定義存儲的接口，如AARepository，但是不寫具體的技術實現
抽象不依賴細節：在domain層里，不依賴其他包的類，如用到數據存儲時，直接調用domain的抽象接口即可
高層通過依賴注入的方式，將基礎設施的實現傳到domain層中
如此一來，我們的架構就不再是分層的結構（從上往下調用）。而是將抽象全部堆在domain層，將細節全部往Application和infrastructure去推。而越抽象越穩定，所以通過這種做法能夠有效減少業務的變更。
架構變成了一種從內而外的邏輯，越往內越抽象，越往外越細節。在北向網關，可以使用rest和dubbo去調用業務邏輯，南向網關可以將數據寫到redis或mq。具體代碼實現
如下業務：發送課程成功了，要發送消息給設備IOT，發送MQ，更新緩存
傳統做法：
void sendCourse(){
//執行業務邏輯
//發送消息給設備IOT
//發送MQ
//更新緩存
}
隨著優化方案的不斷增加，業務邏輯會越堆越多 六邊形架構+EDA做法
public SendCourseService sendCourseService{
void sendCourse(SendCourseCommand command){
//執行業務邏輯并發布發布課程事件
eventBus.push(SendCourseEvent())
}
}
當我們要做更新緩存操作的時候，實際上與業務邏輯沒有什么關系，可以定義一個監聽者去監聽發布課程事件。這個SendCourseCacheHandler類要寫到哪里呢？
public class SendCourseCacheHandler{
private Jedis jedis;
public void deleteCache(SendCourseEvent event){
//刪除緩存
}
}
- 按照抽象往domain寫，細節往外寫的劃分，寫到基礎設施層不合適，因為與業務強相關。
- 寫到domain不合適，因為與redis這些具體實現強相關。
所以這個類應該寫在application層，其實是domain去調用application，所以說。。。這并不是分層架構。我們思考的時候是按抽象程度去判斷應該寫在哪里，而不是從上往下調用。
那這個監聽者如何與業務結合起來呢？這時就發揮了application層的作用了，我們可以將application作為業務組裝的邏輯。
如我們在業務開始之前，將監聽者注冊上去，這樣在業務執行的時候，就可以回調這些監聽者了
public class CourseAppService{
private SendCourseCacheHandler sendCourseCacheHandler;
private SendCourseMQHandler sendCourseMQHandler;
private SendCourseService sendCourseService;
private EventBus eventBus;
public void sendCourse(SendCourseCommand command){
//刪除緩存
eventBus.register(sendCourseCacheHandler);
//發MQ
eventBus.register(sendCourseMQHandler);
sendCourseService.sendCourse(command);
}
}
適合場景：
1.讀/寫比較大的場景 2.對查詢實時性要求不高的場景 3.內部狀態改變會觸發各種數據的同步，如課程完成，課程發布等等等等。。。 4.外部實現可替換，如mq可以隨意替換實現
不適合場景：
只有簡單CRUD的業務，沒有重的業務邏輯，不適合搞那么復雜，因為沒必要抽出domain層
