業務服務庫最小工作單元
這種架構適用於aspnetcore
我所使用的版本是2.2
非常舒服的地方就是startup.cs
可以在configureservices註冊服務
在configure實現中介軟體做aop程式設計，用起來不要太爽
由於net的控制器發現機制 （ 參考 ） 也就是每個業務服務都能擁有自己的最小單元
控制器、模型（實體）、服務、startup.cs
真正做到了微服務（只關注自己的業務，其他一概不關心）
如：
這是乙個類庫，但是它擁有最小webapi服務
有控制器入口，有業務處理服務、有實體模型
同時它只關心order相關的業務
因為demo的緣故，它並沒有vo、qo、dto模型
vo和qo是放在本服務中，dto是放在業務中介者服務中
mediator.domain
後續我們在詳細介紹它
因為工作單元的存在，所以跨庫事務也是可以存在的，原子性就能保持良好，一起提交或者一起回滾，
我個人覺得按業務劃分完全獨立的服務，每乙個服務都是獨立執行，獨立管理自己的業務庫，這樣做代價太大，難點太多，
同乙個專案入口，按業務劃分業務服務庫，每個服務庫單獨管理自己的資料庫，由工作單元去保證跨庫事務的原子性，我覺得是可行的，而且微服務的初衷就是為了解耦，劃分業務服務完全可以達到這個目的，為什麼還要強行去拆分出獨立的程式呢？
業務服務分庫這個留在最後在將最後在講，先說下單個庫的架構
這次我們描述了下業務服務庫最小工作單元和架構和它的前景
思考一種好的架構（十二）
程式集掃瞄庫 referencescan 是什麼？服務間會有各種相互依賴和引用，這勢必會造成爭奪configureservices，到最後牽一髮而動全身。於是很自然的出現了它來解決這個問題，為什麼？為了解決服務爭奪configureservices註冊順序而誕生的庫，他就是各個服務的帶頭人，一定是它...
思考一種好的架構（十二）
事件溯源 tracingsource 資料庫事件溯源實體 table name tracingsource public class tracingsourceentity 執行時間 public datetime executetimer 執行sql public string executesq...
思考一種好的架構（九）
中介者 mediator 為了解除服務間互相引用的問題，單獨劃分出來的乙個服務 它的好處時顯而易見的，服務之間的引用將會變的清晰明了 我只在業務服務庫上使用它，普通服務和基礎設施服務還是自己管自己的，沒有使用mediatr 因為我覺得它對於net core提供的中介者功能並不是很好的用，微軟自帶的i...