思考一种好的架构（二）

 

业务服务库最小工作单元

这种架构适用于AspNetCore

我所使用的版本是2.2

 

非常舒服的地方就是Startup.cs

 

 

 

可以在ConfigureServices注册服务

在Configure实现中间件做AOP编程，用起来不要太爽

由于Net的控制器发现机制 （ 参考 ） 也就是每个业务服务都能拥有自己的最小单元

控制器、模型（实体）、服务、Startup.cs

真正做到了微服务（只关注自己的业务，其他一概不关心）

如：

 

 这是一个类库，但是它拥有最小WebApi服务

有控制器入口，有业务处理服务、有实体模型

同时它只关心Order相关的业务

因为DEMO的缘故，它并没有VO、Qo、Dto模型

Vo和Qo是放在本服务中，DTO是放在业务中介者服务中

Mediator.DoMain

 

 后续我们在详细介绍它

 

因为工作单元的存在，所以跨库事务也是可以存在的，原子性就能保持良好，一起提交或者一起回滚，

我个人觉得按业务划分完全独立的服务，每一个服务都是独立运行，独立管理自己的业务库，这样做代价太大，难点太多，

同一个项目入口，按业务划分业务服务库，每个服务库单独管理自己的数据库，由工作单元去保证跨库事务的原子性，我觉得是可行的，而且微服务的初衷就是为了解耦，划分业务服务完全可以达到这个目的，为什么还要强行去拆分出独立的程序呢？

业务服务分库这个留在最后在将最后在讲，先说下单个库的架构

 

这次我们描述了下业务服务库最小工作单元和架构和它的前景