看了别人写的架构
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,这就很舒服了
普通服务又分普通服务库和业务服务库
普通服务不参与到核心业务逻辑中，它是依赖内部其他服务，做的一个综合服务项
业务服务最明显的一个特点就是会对数据库进行操作，所以任何操作数据库的服务都是业务服务库，
这一部分很简单
我个人对项目架构的认知和演化过程，
若是使用包来管理和划分服务会有怎么样的好处
怎么去划分一个服务，包怎么命名
服务的绝对领域划分