层次介绍

这页只解决一个问题：业务项目接入 Aegis 之后，几层代码分别该放什么。

对大多数项目来说，下面这五层就够用了：

• WebApi
• Contract
• Services
• Dto
• Repository

先有个整体印象

WebApi      接口与宿主
Contract    服务契约
Services    业务流程
Dto         请求与传输对象
Repository  数据访问

换成更直白的话：

• WebApi 负责接请求和启动应用
• Contract 负责定义服务契约
• Services 负责写业务流程
• Dto 负责放请求对象和传输对象
• Repository 负责查库和落库

重要提示：

1. 在 Aegis 规范中，上述每一层都必须是一个独立的 C# 类库项目 (Class Library)，而不是在同一个项目中建几个同名文件夹。
2. 解决方案的名称（如 YourApp）与各层的具体命名没有必然联系。服务层、仓储层和契约层的前缀通常是具体业务模块的名字。 例如：如果你的解决方案叫 Dezhen.Health，但你正在开发结算模块，那么你的类库可能命名为 Settlement.WebApi、Settlement.Contract、Settlement.Services 等。然后通过项目引用将它们串联起来。

WebApi：把应用跑起来，也把接口暴露出去

这一层通常会放：

• Program.cs
• Startup
• Controller
• appsettings.json
• Component.deps.json
• NLog.config

这一层的重点不是写业务，而是把应用接起来。

Contract：定义别人怎么调你的服务

这一层主要放服务接口，也就是业务层对外暴露的契约。常见内容有：

• IUserContract
• IOrderContract
• 其他继承 IBusinessService 的接口

这一层不写实现，只把边界和方法签名定义清楚。

Services：把业务流程串起来

这一层主要处理业务流程，比如：

• 收到一个请求之后，要先查什么
• 要不要校验状态
• 要不要调用多个仓储
• 最后返回什么 DTO

这里有个很容易误会的地方：

Services 不只是“几个 Service 类”的集合，它更像一个大的业务领域层。
业务复杂时，完全可以在这一层下面继续拆，比如：

• 应用服务
• 领域服务
• Rules
• Strategies

不管怎么拆，查库和落库都还是收口到 Repository。

Dto：放请求对象和传输对象

这一层不复杂，按现在这套写法就够：

• API 入参用 XxxRequest
• 传输对象用 XxxDto

比如：

• GetUserRequest
• UserDto
• UserListDto

这一层别放数据库实体，也别放业务逻辑。

Repository：把数据访问收进去

通常会放：

• IDbSource 的实现
• Entity
• Repository
• 需要的数据库 Provider 配置

它负责：

• 查询数据库
• 更新数据库
• 封装 FreeSql 访问

Service 可以调 Repository，但不要直接去碰 IFreeSql。

一个常见的最小结构

YourSolution
├── YourApp.WebApi
├── YourApp.Contract
├── YourApp.Services
├── YourApp.Dto
└── YourApp.Repository

如果业务域很多，再按业务域继续往下分就可以。
文档里常见的 His.* 命名，只是在举业务系统结构的例子，不是要求你的项目一定这么命名。

什么时候看这页最合适

下面两种情况最适合先看这页：

• 你刚接触 Aegis，还不知道几个项目该怎么分
• 你已经能跑起来了，但还是分不清哪些代码该放哪层

如果你现在最着急的是先把项目跑通，还是先看 快速开始。
第一版跑起来之后，再回来看这页，会更容易把各层分清楚。