使用问题域语言命名TypeScript类型的技巧

理解问题域语言

在软件开发中，问题域语言是指描述业务问题、业务规则和业务实体的语言。它通常是业务领域专家、产品经理和客户所使用的语言。例如，在电商领域，问题域语言可能包含诸如“订单”“商品”“购物车”“用户”等词汇，以及描述这些实体之间关系和操作的语句，如“用户将商品添加到购物车”“生成订单”等。

将问题域语言融入到TypeScript类型命名中，能够使代码更贴近业务需求，提高代码的可读性和可维护性。因为当开发人员看到用问题域语言命名的类型时，无需过多猜测就能明白其用途，就像直接在业务层面进行操作一样。

从业务概念到类型命名

识别业务实体

在开始使用问题域语言命名TypeScript类型之前，首先要准确识别业务中的实体。以一个简单的博客系统为例，业务实体可能包括“文章”“作者”“评论”等。我们可以为这些实体创建相应的TypeScript类型。

// 文章实体类型
type Article = {
  title: string;
  content: string;
  author: Author;
  comments: Comment[];
};

// 作者实体类型
type Author = {
  name: string;
  email: string;
};

// 评论实体类型
type Comment = {
  text: string;
  author: Author;
  createdAt: Date;
};

在上述代码中，我们直接使用“Article”“Author”“Comment”这些问题域中的词汇来命名TypeScript类型，清晰地表示了博客系统中的不同实体。

描述实体属性

当确定了业务实体对应的类型后，为类型中的属性命名同样要遵循问题域语言。比如在“Article”类型中，“title”（标题）和“content”（内容）是文章的基本属性，这些命名与业务中对文章的描述是一致的。

type Product = {
  productName: string;
  price: number;
  description: string;
  category: string;
};

在电商产品的类型定义中，“productName”“price”“description”“category”等属性命名都紧密围绕产品在业务中的概念，开发人员可以直观地理解每个属性的含义。

表示实体关系

一对一关系

在业务中，实体之间常常存在各种关系。一对一关系是较为常见的一种。例如，在一个用户管理系统中，每个用户可能有一个唯一的配置文件。

type User = {
  id: number;
  name: string;
  profile: UserProfile;
};

type UserProfile = {
  age: number;
  address: string;
};

这里“User”类型通过“profile”属性与“UserProfile”类型建立了一对一关系，命名方式清晰地体现了这种业务关系，就如同在业务描述中说“用户有一个配置文件”一样。

一对多关系

一对多关系在业务中也很普遍。如在学校管理系统中，一个班级有多个学生。

type Class = {
  className: string;
  students: Student[];
};

type Student = {
  name: string;
  age: number;
};

“Class”类型的“students”属性是一个“Student”类型的数组，明确表示了一个班级对应多个学生的关系，这与学校管理业务中的概念完全契合。

多对多关系

多对多关系相对复杂一些，但同样可以通过合理的类型命名来清晰呈现。例如，在一个项目管理系统中，一个项目可能有多个成员，一个成员也可能参与多个项目。

type Project = {
  projectName: string;
  members: User[];
};

type User = {
  name: string;
  projects: Project[];
};

在上述代码中，“Project”类型的“members”属性和“User”类型的“projects”属性，准确地反映了项目与成员之间多对多的关系，命名方式直观易懂，符合项目管理业务中的实际情况。

操作和行为的类型命名

函数类型命名

在TypeScript中，函数也可以有类型。当用问题域语言来命名函数类型时，能清楚地表达函数的功能。比如在一个文件管理系统中，有一个用于读取文件内容的函数。

type ReadFileFunction = (fileName: string) => string;

const readFile: ReadFileFunction = (fileName) => {
  // 实际读取文件逻辑
  return 'file content';
};

这里将函数类型命名为“ReadFileFunction”，明确表示这是一个用于读取文件的函数类型，与文件管理业务中的操作相对应。

事件处理函数类型命名

在前端开发中，经常会处理各种事件。以网页上的按钮点击事件为例，使用问题域语言命名事件处理函数类型能使代码更易读。

type ButtonClickHandler = () => void;

const handleButtonClick: ButtonClickHandler = () => {
  console.log('Button clicked');
};

const button = document.createElement('button');
button.addEventListener('click', handleButtonClick);

“ButtonClickHandler”这个类型名称清晰地表明这是一个处理按钮点击事件的函数类型，与前端交互业务中的概念一致。

避免命名陷阱

避免过于通用或模糊的命名

在使用问题域语言命名时，要避免使用过于通用或模糊的词汇。比如，在一个财务管理系统中，不能将所有与金额相关的类型都命名为“Amount”。如果有不同用途的金额，如“收入金额”“支出金额”，应该分别命名为“IncomeAmount”和“ExpenseAmount”。

// 不好的命名
type Amount = number;

// 好的命名
type IncomeAmount = number;
type ExpenseAmount = number;

这样的命名能更准确地反映业务含义，避免开发过程中的混淆。

保持命名一致性

在整个项目中，要保持使用问题域语言命名的一致性。例如，在电商系统中，如果将商品的唯一标识命名为“productId”，那么在涉及到订单中的商品标识时，也应命名为类似的形式，如“orderProductId”，而不应突然使用“productNumber”等不同的命名方式。

// 保持一致性的示例
type Product = {
  productId: string;
  productName: string;
};

type OrderItem = {
  orderProductId: string;
  quantity: number;
};

通过保持命名一致性，能够让开发人员更容易理解和维护代码，减少因命名差异带来的困惑。

结合设计模式与问题域语言命名

单例模式中的类型命名

单例模式在软件开发中经常使用。以日志记录器为例，假设我们使用单例模式实现一个日志记录器，在TypeScript中进行类型命名时，要结合问题域语言。

type Logger = {
  log(message: string): void;
};

const LoggerSingleton: Logger = {
  log(message) {
    console.log(`[LOG] ${message}`);
  }
};

export default LoggerSingleton;

这里将日志记录器类型命名为“Logger”，符合软件开发中对日志记录这一业务操作的描述，同时通过单例模式确保整个应用中只有一个日志记录器实例。

工厂模式中的类型命名

工厂模式用于创建对象。在游戏开发中，假设有一个角色工厂用于创建不同类型的角色。

type Character = {
  name: string;
  health: number;
  attack(): void;
};

type CharacterFactory = {
  createCharacter(type: string): Character;
};

const characterFactory: CharacterFactory = {
  createCharacter(type) {
    if (type === 'warrior') {
      return {
        name: 'Warrior',
        health: 100,
        attack() {
          console.log('Warrior attacks');
        }
      };
    } else if (type ==='mage') {
      return {
        name: 'Mage',
        health: 80,
        attack() {
          console.log('Mage casts spell');
        }
      };
    }
  }
};

“Character”类型表示游戏中的角色，“CharacterFactory”类型表示创建角色的工厂，这种命名方式结合了游戏开发中的业务概念，清晰地体现了工厂模式在游戏角色创建中的应用。

处理复杂业务逻辑下的类型命名

业务规则嵌套时的类型命名

在一些复杂的业务场景中，业务规则可能存在嵌套。例如，在一个金融贷款审批系统中，审批规则可能根据不同的用户信用等级和贷款金额范围有不同的处理方式。

type CreditLevel = 'high' |'medium' | 'low';

type LoanApplication = {
  applicantName: string;
  loanAmount: number;
  creditLevel: CreditLevel;
};

type LoanApprovalRule = {
  creditLevel: CreditLevel;
  minLoanAmount: number;
  maxLoanAmount: number;
  approvalFunction: (application: LoanApplication) => boolean;
};

const highCreditRule: LoanApprovalRule = {
  creditLevel: 'high',
  minLoanAmount: 1000,
  maxLoanAmount: 100000,
  approvalFunction(application) {
    return application.loanAmount >= 1000 && application.loanAmount <= 100000;
  }
};

const mediumCreditRule: LoanApprovalRule = {
  creditLevel:'medium',
  minLoanAmount: 500,
  maxLoanAmount: 50000,
  approvalFunction(application) {
    return application.loanAmount >= 500 && application.loanAmount <= 50000;
  }
};

const lowCreditRule: LoanApprovalRule = {
  creditLevel: 'low',
  minLoanAmount: 100,
  maxLoanAmount: 10000,
  approvalFunction(application) {
    return application.loanAmount >= 100 && application.loanAmount <= 10000;
  }
};

在上述代码中，通过“LoanApplication”类型表示贷款申请，“LoanApprovalRule”类型表示贷款审批规则，并且在规则中嵌套了信用等级、金额范围以及审批函数等业务逻辑相关的内容，类型命名紧密围绕金融贷款审批的业务规则，使复杂的业务逻辑在代码层面清晰呈现。

状态机中的类型命名

状态机在处理具有不同状态转换的业务场景中非常有用。以一个电商订单状态机为例，订单可能有“未支付”“已支付”“已发货”“已完成”等状态。

type OrderStatus = 'unpaid' | 'paid' |'shipped' | 'completed';

type Order = {
  orderId: string;
  status: OrderStatus;
  transition(toStatus: OrderStatus): void;
};

const order: Order = {
  orderId: '12345',
  status: 'unpaid',
  transition(toStatus) {
    this.status = toStatus;
    console.log(`Order status changed to ${toStatus}`);
  }
};

order.transition('paid');

“OrderStatus”类型定义了订单可能的状态，“Order”类型表示订单本身，包含状态以及状态转换的方法。这种类型命名方式直观地反映了电商订单状态机的业务逻辑，开发人员可以很容易地理解和维护订单状态相关的代码。

与团队协作中的类型命名规范

制定统一的命名规范文档

在团队开发中，为了确保所有成员都能正确使用问题域语言进行TypeScript类型命名，需要制定一份统一的命名规范文档。该文档应包括常见业务概念的命名示例、命名的基本原则（如避免通用模糊命名、保持一致性等）以及特殊情况下的命名指导。

例如，文档中可以明确规定在电商项目中，商品相关的类型命名应以“Product”为前缀，订单相关的类型命名应以“Order”为前缀。这样团队成员在创建新的类型时，能够遵循统一的规范，减少命名差异。

代码审查中的命名检查

代码审查是保证代码质量的重要环节。在代码审查过程中，要特别关注TypeScript类型命名是否符合问题域语言的规范。审查人员应检查命名是否清晰准确地反映了业务含义，是否与团队制定的命名规范一致。

如果发现命名不符合规范的情况，应及时与代码作者沟通，解释正确的命名方式及其重要性，确保代码的可读性和可维护性。通过代码审查中的命名检查，能够不断强化团队成员对使用问题域语言命名类型的认识，提高整个项目的代码质量。

与其他技术栈结合时的类型命名

与后端API交互中的类型命名

当前端应用使用TypeScript与后端API进行交互时，类型命名要保持一致性。假设后端API返回一个用户信息的JSON数据，前端可以根据这个数据结构定义相应的TypeScript类型。

// 假设后端API返回的用户数据结构
// {
//   "id": 1,
//   "name": "John Doe",
//   "email": "johndoe@example.com"
// }

type UserFromAPI = {
  id: number;
  name: string;
  email: string;
};

async function fetchUser(): Promise<UserFromAPI> {
  const response = await fetch('/api/user');
  const data = await response.json();
  return data;
}

这里将从API获取用户信息对应的类型命名为“UserFromAPI”，明确表示这是与后端API交互相关的用户类型，使前端开发人员能够清楚地知道该类型的来源和用途。

与数据库交互中的类型命名

在全栈开发中，与数据库交互也是常见的场景。以使用SQLite数据库为例，假设数据库中有一个“products”表，包含“id”“name”“price”等字段。

import sqlite3 from 'sqlite3';

type ProductFromDB = {
  id: number;
  name: string;
  price: number;
};

const db = new sqlite3.Database('test.db');

function getProducts(): Promise<ProductFromDB[]> {
  return new Promise((resolve, reject) => {
    db.all('SELECT * FROM products', (err, rows) => {
      if (err) {
        reject(err);
      } else {
        resolve(rows as ProductFromDB[]);
      }
    });
  });
}

“ProductFromDB”类型表示从数据库中获取的产品信息，这种命名方式体现了与数据库交互的业务背景，方便开发人员在处理数据库相关操作时理解数据结构。

通过以上各个方面的介绍，我们详细阐述了使用问题域语言命名TypeScript类型的技巧。从业务概念的识别到复杂业务逻辑处理，再到团队协作和与其他技术栈结合，合理运用这些技巧能够显著提升代码的质量和可维护性，使TypeScript代码更贴近业务需求，为软件开发项目带来诸多益处。无论是小型项目还是大型企业级应用，这些技巧都具有重要的实践价值。