思考一种好的架构(二)

 

业务服务库最小工作单元

这种架构适用于AspNetCore

我所使用的版本是2.2

 

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

 

 

 

可以在ConfigureServices注册服务

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

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

控制器、模型(实体)、服务、Startup.cs

真正做到了微服务(只关注自己的业务,其他一概不关心)

如:

 

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

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

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

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

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

Mediator.DoMain

 

 后续我们在详细介绍它

 

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

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

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

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

 

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

posted @ 2020-03-31 16:39  AnAng  阅读(121)  评论(0编辑  收藏  举报