Bitwarden 贡献文档
⮐ Bitwarden Contributing Documentation我的博客联系我
  • 关于
  • 入门
    • 概述
    • 工具
    • 服务器
      • 设置指南
      • 高级服务器设置
      • 数据库
        • MSSQL
        • 实体框架
      • 事件日志
      • Ingress 隧道
      • SCIM
      • 自托管指南
      • 系统管理门户
      • 单点登录 (SSO)
        • 本地 IdP
        • Okta
      • 故障排除
      • 用户机密
      • 公共 API
    • 网页客户端
      • 网页密码库
        • WebAuthn
      • 浏览器端
        • 生物识别解锁
        • Firefox 隐私模式
      • 桌面端
        • Mac App Store Dev
        • Microsoft Store
        • Native Messaging Test Runner
        • 更新测试
      • CLI
      • 故障排除
    • 移动端
      • Android
        • F-Droid
      • iOS
      • .NET MAUI (legacy)
        • Android
        • iOS
        • watchOS
    • SDK
      • 内部 SDK
      • Secrets Manager
        • Integrations
          • Kubernetes
    • 业务 App
      • 目录连接器
        • JumpCloud
        • OpenLDAP Docker 服务器
      • Key Connector
      • Splunk App
  • 贡献
    • 贡献
    • 代码样式
      • =Android & Kotlin
      • Angular & TypeScript
      • C#
      • =Rust
      • T-SQL
      • =Swift
      • Tailwind
    • 数据库迁移
      • 进化数据库设计
    • 提交签名
    • 拉取请求
      • =贡献审查程序
      • 分支
      • 代码审查
      • UI 审查 - Chromatic
    • 无障碍
    • 依赖管理
    • 功能标记
    • 模板存储库
    • 测试
      • =数据库集成测试
      • 负载测试
      • 单元测试
        • 命名约定
        • 测试结构
    • 修改用户机密
  • 架构
    • 架构
    • 架构决策记录 (ADR)
      • 0001 - Angular Reactive Forms
      • 0002 - Public API for modules
      • 0003 - Adopt Observable Data Services for Angular
      • 0004 - Refactor State Service
      • 0005 - Refactor Api Service
      • 0006 - Clients: Use Jest Mocks
      • 0007 - Manifest V3 sync Observables
      • 0008 - Server: Adopt CQRS
      • 0009 - Composition over inheritance
      • 0010 - Angular Modules
      • 0011 - Scalable Angular Clients folder structure
      • 0012 - Angular Filename convention
      • 0013 - Avoid layered folder structure for request/response models
      • 0014 - Adopt Typescript Strict flag
      • 0015 - Short Lived Browser Services
      • 0016 - Move Decryption and Encryption to Views
      • 0017 - Use Swift to build watchOS app
      • 0018 - Feature management
      • 0019 - Adoption of Web Push
      • 0020 - Observability with OpenTelemetry
      • 0021 - Logging to Standard Output
      • =0022 - Authorization
      • =0023 - Identifying Integrated Clients
    • 移动客户端架构
      • =Android
      • =iOS
        • =推送通知故障排除提示
      • =.NET MAUI (legacy)
        • =概述
        • watchOS
    • =SDK 架构
      • =数据模型
      • =依赖
      • Password Manager
        • Web
          • =互操作性
      • =Secrets Manager
      • =服务器绑定
      • =版本控制和破坏性更改
    • 网络客户端架构
      • 概述
      • 数据模型
      • 表示层
        • Angular
        • CLI
      • =依赖注入
      • 服务层
        • Vision
        • 实现
    • 服务器架构
    • 深度剖析
      • 身份验证
        • 双重身份验证
      • =授权
      • =浏览器自动填充
        • 收集页面详细信息
        • 生成并执行填充脚本
        • 表单提交检测
        • Shadow DOM
        • =内联自动填充菜单
      • Captcha
      • =只读数据库副本
      • 事件日志
      • =FIDO2 和通行密钥
        • =凭据
        • =操作
        • =命名惯例
        • =实现
          • =提供程序
            • =浏览器扩展
          • =依赖方
            • =用于解密的通行密钥
        • =术语表
      • 推送通知
        • 移动端推送通知
        • 其他客户端推送通知
      • =SSH 密钥和代理
        • =SSH 代理
      • =状态提供程序框架
        • =派生状态
    • =安全
      • =定义
      • =原则
        • =P01 - 锁定的密码库是安全的
        • =P02 - 半受损设备密码库的有限安全性
        • =P03 - 完全损坏的系统没有安全性
        • =P04 - 控制密码库数据的访问权限
        • =P05 - 将安全漏洞的影响降至最低
      • =要求
由 GitBook 提供支持
在本页
  • CQRS (ADR-0008)
  • 命令与查询
  • 编写命令或查询
  • 维护命令/查询的卓越性
  • 避免 Primitive Obsession
  • 避免过多的可选参数
  1. 架构

服务器架构

上一页实现下一页深度剖析

最后更新于3个月前

对应的

CQRS ()

我们的服务器架构使用命令和查询职责分离 () 的模式。

此模式的主要目标是分解专注于单个实体的大型服务(例如 CipherService ),并转向基于操作或任务的更小、可重用的类(例如 CreateCipher )。将来,这可能会带来其他好处,例如将命令排队执行,但目前的重点是拥有更小的、可重用的代码块。

命令与查询

命令是写入操作,例如 RotateOrganizationApiKeyCommand。他们永远不应该从数据库中读取数据。

查询是读取操作,例如 GetOrganizationApiKeyQuery。他们永远不应该写入数据到数据库。

数据库是我们处理的最常见的数据源,但其他数据源也是可能的。例如,查询还可以从远程服务器获取数据。

每个查询或命令应该有一个单一的职责。例如:删除用户、获取许可证文件、轮换 API 密钥。它们是围绕动词或动作(例如 RotateOrganizationApiKeyCommand )而不是域名或实体(例如 ApiKeyService )设计的。

编写命令或查询

一个简单的查询可能只是一个从数据库获取数据的存储库调用。(我们已经使用存储库,这不是我们在这里关心的)但是,更复杂的查询可能需要围绕存储库调用的附加逻辑,这将需要它们自己的类。命令总是需要自己的类。

类、接口和公共方法应以操作命名。例如:

namespace Bit.Core.OrganizationFeatures.OrganizationApiKeys;

public class RotateOrganizationApiKeyCommand : IRotateOrganizationApiKeyCommand
{
  public async Task<OrganizationApiKey> RotateApiKeyAsync(OrganizationApiKey organizationApiKey)
  {
    ...
  }
}

查询/命令应该只公开运行完整操作的公共方法。它不应该有公共助手方法。

目录结构和命名空间应按功能组织。接口应存储在单独的子文件夹中。例如:

  Core/
    └── OrganizationFeatures/
        └── OrganizationApiKeys/
            ├── Interfaces/
            │   └── IRotateOrganizationApiKeyCommand.cs
            └── RotateOrganizationApiKeyCommand.cs

维护命令/查询的卓越性

通过分离读写操作,CQRS 鼓励我们保持类之间的松散耦合。在我们的代码库中使用 CQRS 时,需要遵循两条黄金法则:

  • 命令永远不应该读取,查询永远不应该写入

  • 命令和查询不应该互相调用

这两者都会导致类之间的紧密耦合,减少代码重用的机会,并将命令/查询的区别混为一谈。

通常可以通过以下方式避免这些问题:

  • 编写命令,以便它们在参数中接收所需的所有数据,而不是自己获取数据

  • 按顺序调用查询和命令(一个接一个),沿调用链传递结果

例如,如果我们需要更新组织的 API 密钥,可能会倾向于使用 UpdateApiKeyCommand 来获取当前 API 密钥然后更新它。但是,我们可以将其分解为两个单独的查询/命令,分别调用:

var currentApiKey = await _getOrganizationApiKeyQuery.GetOrganizationApiKeyAsync(orgId);
await _rotateOrganizationApiKeyCommand.RotateApiKeyAsync(currentApiKey);

这也有单元测试的好处 - 您可以简单地使用 Autodata 属性提供不同的参数值,而不是在模拟查询结果时进行冗长的「编排」阶段。

在实际情况下,您的命令和查询应该获取并返回整个对象(例如 User )而不是单个属性(例如 userId)。

避免过多的可选参数

过多的可选参数很快就会变得难以使用。相反,请考虑使用方法重载来为命令或查询提供不同的入口点。

避免

官方页面地址
ADR-0008
Command and Query Responsibility Segregation - CQRS
Primitive Obsession