看了别人写的架构
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进行继承，单独划分成一个包是因为从服务角度上来说，路由服务就是一个服务，即使功能在简单，他也应该独立出来。
这一部分很简单
我个人对项目架构的认知和演化过程，
若是使用包来管理和划分服务会有怎么样的好处
怎么去划分一个服务，包怎么命名