接上文，我們已經粗略的拆分了單層應用，主要講一些基礎設施功能代碼抽離出去，但是業務代碼部分還是比較臃腫。
接下來就準備將業務部分抽離一下。
思路
前面將一些基礎的部分抽離出去了，接下來就是業務和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的話，會顯得有些多餘，所以在後續我們應該考慮將這部分基礎設施再做一下細緻化的拆分。
那麼下一篇文章我們將繼續做我們的多層應用升級的拆分優化。
歡迎進羣催更。
