​

上一章我们建立了一个典型的面向领域设计的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，进行接口化改造

​