业务服务库最小工作单元
这种架构适用于AspNetCore
我所使用的版本是2.2
非常舒服的地方就是Startup.cs
可以在ConfigureServices注册服务
在Configure实现中间件做AOP编程，用起来不要太爽
由于Net的控制器发现机制 （ 参考 ） 也就是每个业务服务都能拥有自己的最小单元
控制器、模型（实体）、服务、Startup.cs
真正做到了微服务（只关注自己的业务，其他一概不关心）
如：
这是一个类库，但是它拥有最小WebApi服务
有控制器入口，有业务处理服务、有实体模型
同时它只关心Order相关的业务
因为DEMO的缘故，它并没有VO、Qo、Dto模型
Vo和Qo是放在本服务中，DTO是放在业务中介者服务中
Mediator.DoMain
后续我们在详细介绍它
因为工作单元的存在，所以跨库事务也是可以存在的，原子性就能保持良好，一起提交或者一起回滚，
我个人觉得按业务划分完全独立的服务，每一个服务都是独立运行，独立管理自己的业务库，这样做代价太大，难点太多，
同一个项目入口，按业务划分业务服务库，每个服务库单独管理自己的数据库，由工作单元去保证跨库事务的原子性，我觉得是可行的，而且微服务的初衷就是为了解耦，划分业务服务完全可以达到这个目的，为什么还要强行去拆分出独立的程序呢？
业务服务分库这个留在最后在将最后在讲，先说下单个库的架构
这次我们描述了下业务服务库最小工作单元和架构和它的前景