看了別人寫的架構
https://www.cnblogs.com/legendxian/archive/2012/06/18/2553111.html#!comments
https://www.cnblogs.com/laozhang-is-phi/p/9806335.html
年初的架構
以上架構都是以技術來劃分一個庫（包）
比如最常見的Tool Library
感覺差距不是一般的大
於是想到使用nuget包的方式來編寫服務
做成一個單體SOA架構的項目
如：
首先聲明：我月薪只有6K，這個東西只是我的一些不成熟的想法,各位大佬噴我的時候，輕一點哈。
解決的問題：
在協同開發的時候，不經要面對你的代碼，更要看別人的代碼，其他組員使用的技術可能並不瞭解，不敢刪，也不敢動，沒有註釋的情況下就更加糟糕了，如果要改這段代碼必須得先熟悉運用的技術，然後閱讀他的代碼理解他寫代碼的思路，最後才能進行更改，最好的辦法就是看不見那部分代碼，就不會覺得煩。
封裝成包的方式就很好，只要在程序入口加上一段代碼就行了。
即使如：
APIDOC.Swager
EventBus.MediatR
Mapping.AutoMapper
...
對某個開源庫的在封裝，也只是爲了讓這個開源庫更好的提供服務，我需要某些服務，纔會選擇某個技術庫。
關於包命名確實有問題
應該改成
公司名.項目名.包名（服務名）.架構名（技術名）
比如：
Work.Mall.APIDoc.Swagger
Work.Mall.Products
Work.Mall.APIRoute
第一個是一個APIDOC服務，對Swagger的封裝，以便爲系統更好的提供服務
第二個是一個商品服務,它提供的服務是商品服務，沒有封裝任何技術，純粹是用來存放業務邏輯的，
第三個是一個AIPRouth服務，它負責修改API路由的規則，正確導向到每一個服務庫
Work.Mall.APIDoc.Swagger
之所以要把Swagger也封裝成一個服務，是因爲封裝這個包的人熟悉Swagger這個技術，但是其他人並不瞭解，若是寫在其他組員看得到的地方難免會加大項目複雜度。
其他組員只要知道怎麼用，並不需要知道怎麼實現
Work.Mall.Products
這個也是我們業務上主要服務，具體後續在說
Work.Mall.APIRoute
它提供了一個路由分配服務，很簡單，就只有一個特性，對Routh進行繼承，單獨劃分成一個包是因爲從服務角度上來說，路由服務就是一個服務，即使功能在簡單，他也應該獨立出來。
其中關於邊境和引用問題
推薦服務間使用包來進行引用而不是路徑引用
這會導致一個問題，一個核心庫更新後需要把所有引用他的庫全部更新，才能達到代碼的最新版，
其實不管是路徑引用還是包引用都有這個問題，只是包引用更麻煩，需要一個一個子庫去辨別更新，
路徑引用則不會有這個問題，直接錯誤列表裏查找就行了
基礎服務和普通服務的劃分
我是這麼定義的，
任何服務只引用外部服務給內部使用而不會有內部依賴，那麼它就是一個基礎設施庫
任何服務引用了內部其他服務，那麼它就是一個普通服務
不能存在既引用外部服務也引用內部服務的庫，這是絕對不行的
如：CQRS的功能和工作單元的功能，最早我是把他們劃分在ORM中，因爲特別好寫代碼，而且從大體邏輯上來說，都是ORM的繁衍物，但是CQRS進行寫操作的時候需要發個寫操作事件通知另一個服務去做事件回溯持久化，這就有內部依賴了，寫完後總感覺有種東西堵在心口，最後我把他們拆分成出來，工作單元只依賴ORM,CQRS依賴ORM和EventBus,這就很舒服了
普通服務又分普通服務庫和業務服務庫
普通服務不參與到核心業務邏輯中，它是依賴內部其他服務，做的一個綜合服務項
業務服務最明顯的一個特點就是會對數據庫進行操作，所以任何操作數據庫的服務都是業務服務庫，
這一部分很簡單
我個人對項目架構的認知和演化過程，
若是使用包來管理和劃分服務會有怎麼樣的好處
怎麼去劃分一個服務，包怎麼命名
服務的絕對領域劃分