業務服務庫最小工作單元
這種架構適用於AspNetCore
我所使用的版本是2.2
非常舒服的地方就是Startup.cs
可以在ConfigureServices註冊服務
在Configure實現中間件做AOP編程，用起來不要太爽
由於Net的控制器發現機制 （ 參考 ） 也就是每個業務服務都能擁有自己的最小單元
控制器、模型（實體）、服務、Startup.cs
真正做到了微服務（只關注自己的業務，其他一概不關心）
如：
這是一個類庫，但是它擁有最小WebApi服務
有控制器入口，有業務處理服務、有實體模型
同時它只關心Order相關的業務
因爲DEMO的緣故，它並沒有VO、Qo、Dto模型
Vo和Qo是放在本服務中，DTO是放在業務中介者服務中
Mediator.DoMain
後續我們在詳細介紹它
因爲工作單元的存在，所以跨庫事務也是可以存在的，原子性就能保持良好，一起提交或者一起回滾，
我個人覺得按業務劃分完全獨立的服務，每一個服務都是獨立運行，獨立管理自己的業務庫，這樣做代價太大，難點太多，
同一個項目入口，按業務劃分業務服務庫，每個服務庫單獨管理自己的數據庫，由工作單元去保證跨庫事務的原子性，我覺得是可行的，而且微服務的初衷就是爲了解耦，劃分業務服務完全可以達到這個目的，爲什麼還要強行去拆分出獨立的程序呢？
業務服務分庫這個留在最後在將最後在講，先說下單個庫的架構
這次我們描述了下業務服務庫最小工作單元和架構和它的前景