跳到主要内容

[草稿] 统一分层模型

Nebula 大多数后端业务模块都遵循 api / core / local / remote / service 分层。这个结构的价值，不是为了“看起来规范”，而是为了让同一份业务能力既能本地集成，也能独立部署，还能被其他服务远程调用。

每层分别做什么​

*-api​

  • 定义 DTO、Command、Query、服务接口等稳定契约
  • 让其他模块可以只依赖契约，而不依赖具体实现

*-core​

  • 放领域实现、DAO、业务编排和核心配置
  • 这是业务真正发生的地方

*-local​

  • 暴露本地接入层，通常是 Controller + core
  • 适合单体项目直接引入

*-remote​

  • 暴露远程调用接入层
  • 适合微服务场景下的消费者服务使用

*-service​

  • 独立服务启动模块
  • 用于把该业务能力作为独立服务运行

一个典型理解方式​

以 nebula-auth 为例：

  • 你想在单体工程里直接使用登录和权限能力，就依赖 nebula-auth-local
  • 你想把认证中心独立部署出来，就启动 nebula-auth-service
  • 其他服务想远程调用认证中心，就依赖 nebula-auth-remote

也就是说，这不是三套实现，而是一套能力的三种接入姿势。

对新增模块意味着什么​

如果你准备在 Nebula 中继续新增业务领域，最自然的方式不是直接堆在一个大模块里，而是延续现有结构：

  1. 在 api 暴露清晰的领域契约
  2. 在 core 实现业务逻辑
  3. 在 local 决定本地 HTTP 暴露方式
  4. 在 remote 决定远程调用方式
  5. 在 service 提供独立启动能力

这样做的好处是，文档、配置、测试和接入方式都能沿用项目中已存在的模式。

和前端的关系​

前端最常接触的是 local 或 service 暴露出来的 HTTP 接口，但真正保证“同一个模块能被多种场景复用”的，是后端这套分层。前端开发者可以把它简单理解为：Nebula 后端已经帮你把“单体集成”和“远程服务化”都留好了出口。