ServiceStack实现依赖数据库业务逻辑的优雅架构方案

核心原则是避免通过调用对外暴露的Query接口实现内部业务校验，这类自调用属于不必要的依赖，既影响性能也会提升后续维护成本，推荐按以下方式实现：

1. 利用AutoQuery CRUD内置的生命周期钩子实现校验，无需重写完整服务 #

ServiceStack的AutoQuery CRUD本身提供了数据持久化前后的扩展点，不需要你自定义完整的Booking Service，也不用依赖QueryRooms、QueryBookings这类对外请求DTO：

• 继承CrudEvents<T>实现Booking实体的CRUD事件处理类，注册到容器后框架会自动在对应操作节点执行钩子逻辑
• 直接在钩子中注入数据访问依赖完成校验，跳过对外接口的调用链路，示例代码如下：

public class BookingCrudEvents : CrudEvents<Booking>
{
    private readonly IDbConnectionFactory _dbFactory;
    // 直接注入数据库连接工厂，无其他服务依赖
    public BookingCrudEvents(IDbConnectionFactory dbFactory) => _dbFactory = dbFactory;

    public override void OnBeforeCreate(Booking booking, IRequest req, IResponse res)
    {
        ThrowIfNoAvailableRooms(booking);
    }

    public override void OnBeforeUpdate(Booking booking, IRequest req, IResponse res)
    {
        ThrowIfNoAvailableRooms(booking);
    }

    private void ThrowIfNoAvailableRooms(Booking booking)
    {
        using var db = _dbFactory.OpenDbConnection();
        // 直接查询酒店总房量，不需要走QueryRooms接口
        var totalRooms = db.Scalar<int>(
            "SELECT TotalRooms FROM Hotels WHERE Id = @HotelId",
            new { booking.HotelId }
        );

        // 直接查询时间重叠的已预订记录数，更新操作排除当前记录本身
        var bookedCount = db.Scalar<int>(
            @"SELECT COUNT(1) FROM Bookings 
              WHERE HotelId = @HotelId
              AND CheckIn < @CheckOut 
              AND CheckOut > @CheckIn
              AND Id <> @ExcludeId",
            new { 
                booking.HotelId, 
                booking.CheckIn, 
                booking.CheckOut, 
                ExcludeId = booking.Id 
            }
        );

        if (bookedCount >= totalRooms)
            throw new ArgumentException("所选日期区间内无可用房间，无法保存预订");
    }
}

这种实现的优势：

• 校验逻辑和对外接口完全解耦，后续调整Query接口的字段、权限、返回结构都不会影响核心业务规则
• 直接走数据库查询，比调用内部服务少了过滤器、序列化、权限校验等冗余流程，性能更高
• 不需要重写完整的Create/Update逻辑，AutoQuery自带的参数校验、字段过滤、审计字段自动赋值等能力都能正常保留

2. 多入口复用时抽离独立领域服务 #

如果除了AutoQuery的新增、更新接口，后续还有批量导入、后台人工改单、第三方渠道同步等其他入口需要做库存校验，可以把校验逻辑抽成无状态的领域服务：

• 定义如IBookingAvailabilityService的接口，封装库存校验逻辑，仅依赖数据访问层，不绑定任何请求DTO或HTTP上下文
• 所有需要校验的入口（CRUD钩子、自定义服务、后台任务）直接注入该服务即可，避免逻辑重复

3. 高并发场景补充数据库层兜底 #

如果业务并发量较高，仅靠应用层校验可能出现并发请求同时通过校验导致超卖的问题，需要补充数据库层面的约束：

• 给Booking实体加[OptimizeLock]特性开启乐观锁，避免并发更新冲突
• 可额外按日期+酒店维度建立库存计数表，配合数据库事务、行级锁做最终兜底，从数据层杜绝超卖可能

你之前设想的实现方式本质是把对外的查询接口当成内部数据访问层用，属于常见的设计误区：对外服务的契约是面向调用方设计的，承载了权限、限流、格式转换等额外逻辑，不适合作为内部业务逻辑的依赖。

内容的提问来源于stack exchange，提问作者pvieira