接上文，我们已经粗略的拆分了单层应用，主要讲一些基础设施功能代码抽离出去，但是业务代码部分还是比较臃肿。
接下来就准备将业务部分抽离一下。
思路#
前面将一些基础的部分抽离出去了，接下来就是业务和API方面，这里准备再抽离出两个类库。分别是Api和Application。
Api主要是接口部分的代码。
Application主要是业务应用部分的代码。
开始迁移#
Wheel.Application#
新建一个类库Wheel.Application，将我们的Service代码全部迁移过去。
Application需要引用依赖Core和Data项目。
Wheel.Api#
新建一个类库Wheel.Api，将Host中的Controllers目录迁移过去。
由于Api中需要用来Application的Service，所以Api需要引用依赖Application项目。
到这里之后，我们再看Host，又相对简洁了一部分，Host只需要引用API项目即可。
这里由于我们把控制器抽离成类库，所以我们需要使用AddApplicationPart来加载我们的控制器，否则API无法生效。在Program中添加以下代码即可：
builder.Services.AddControllers()
.AddApplicationPart(typeof(WheelControllerBase).Assembly)
调整目录结构#
到了这里，我们大体的层次已经拆分清晰了，接下来，我们可以把目录结构调整以下，使解决方案更加清晰。
这里我们分成两部分，一个是framwork，一个是src。
framwork主要用于框架部分的功能，如基础设施。
src则是我们的业务部分，包括Api，Application，Data，Domain，Shared，Host。
调整完后，解决方案看起来稍微清晰了些。
这样目前我们的分层升级已经可以说初步完成了，但是在Host项目中，仍旧还有许多功能代码没有拆分，如EventBus，FileStoreages， Authorization，Localization等，这部分又算基础设施功能，一部分又有一定的业务属性。后续我们应该考虑如何将这些功能抽象拆分出来。
在Core项目中，包含了我们所有的基础功能，但是有些项目可能只需要部分功能却引用整一块Core的话，会显得有些多余，所以在后续我们应该考虑将这部分基础设施再做一下细致化的拆分。
那么下一篇文章我们将继续做我们的多层应用升级的拆分优化。
欢迎进群催更。
