[.Net]使用Soa库+Abp搭建微服务项目框架（二）：面向服务体系的介绍
作者：互联网
上一章我们建立了一个典型的面向领域设计的Abp小项目，如果按照常规的开发方式，会遇到什么问题呢？
先来完善一下这个小项目，在定义好各实体类后，运行Miguration并向数据库里写入一些初始数据。
现在整个项目的依赖引用图如下，每一个都有独立的引用路线，互不干涉。
简略图如下
假设现在有一个需求，MainService业务需要用到Service1和Service2 中的数据，如何操作？
在使用Abp框架时，传统开发方式是先建立领域层服务，应用层中调用领域层服务（Manager）并返回给UI层，完成整个业务流程；或者更简单方式是直接在应用层注入仓储对象，拿到实体类做数据操作。
我们分别来完成这两个方式实现这一需求。
首先在MatoProject.MainService.Application项目中建立一个应用层服务MainService.cs并继承AsyncCrudAppService。
建立一个方法GetExtends，用于查询Entity1，Entity2 中的Type和Num字段。
方式1: 模拟传统方式在应用层获取数据：
看看依赖情况：
若是使用方式1， 在注入仓储对象的时候，势必直接引用了这两个服务的领域层，造成了耦合。
方式2: 模拟传统方式在领域层获取数据：
在Domain层中分别建立两个领域服务（Manager），并且定义GetType和GetNum方法，分别用于获取Entity1，Entity2 中的Type和Num字段
在MainService.cs的GetExtends方法更改分别调用两个Manager 的GetType与GetNum方法，从中获取Type和Num值。
拼接完成后返回结果
看看依赖情况：
若是使用方式2， 在注入领域服务（Manager）时，也势必直接引用了这两个服务的领域层，造成了项目之间的耦合
若是在MainService服务层应用了Service1 和 Service2 的话，则项目的各个模块边界将变得不明晰，上一章所讨论的依据上下文边界划分服务，也将变得没有意义。
简略图如下
现在，我们需要考虑用面向服务体系的架构改造，将MainService，Service1， Service2 解耦。
若要独立成服务，则要考虑引用其抽象，也就是要做接口化的改造，使其之间的状态变为弱关联
下一章节将介绍如何结合Abp，进行接口化改造
标签：Soa,服务,领域,Abp,Manager,Net,应用层,MainService 来源： https://www.cnblogs.com/jevonsflash/p/15806218.html