看了別人寫的架構
https://www.cnblogs.com/legendxian/archive/2012/06/18/2553111.html#!comments
https://www.cnblogs.com/laozhang-is-phi/p/9806335.html
年初的架構
感覺差距不是一般的大
於是想到使用nuget包的方式來編寫服務
做成一個SOA架構的項目
如：
解決的問題：
在協同開發的時候，不經要面對你的代碼，更要看別人的代碼，其他組員使用的技術可能並不瞭解，不敢刪，也不敢動，沒有註釋的情況下就更加糟糕了，如果要改這段代碼必須得先熟悉運用的技術，然後閱讀他的代碼理解他寫代碼的思路，最後才能進行更改，最好的辦法就是看不見那部分代碼，就不會覺得煩。
封裝成包的方式就很好，只要在程序入口加上一段代碼就行了。
以上架構都是以技術來劃分一個庫（包），我這個思路是以服務來建庫，
即使如：
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進行繼承，單獨劃分成一個包是因爲從服務角度上來說，路由服務就是一個服務，即使功能在簡單，他也應該獨立出來。
這一部分很簡單
我個人對項目架構的認知和演化過程，
若是使用包來管理和劃分服務會有怎麼樣的好處
怎麼去劃分一個服務，包怎麼命名