NX库循环依赖问题咨询：NestJS/GraphQL/TypeORM实体架构设计

核心调整：放弃单实体拆分，按业务域聚合库 #

按单个实体拆库的方式必然会因实体强关联产生循环依赖，同时触发大面积重建。正确的做法是把关联紧密的实体聚合到同一个业务域库，比如：

• @app/identity-domain：包含customer、company实体及相关仓库、GraphQL对象、用例（用户与公司属于身份管理域，关联紧密）
• @app/financial-assets-domain：包含wallet、credit card实体及相关逻辑（钱包与信用卡属于资产管理域）
• @app/expense-tracking-domain：包含expense实体及相关逻辑（费用属于消费追踪域）

每个域库内部可完整实现该业务域的闭环逻辑，域与域之间通过**明确的接口/数据传输对象（DTO）**交互，而非直接引用其他域的实体。

抽离共享核心库，统一依赖入口 #

创建@app/core库，存放所有业务域通用的内容：

• TypeORM基础实体（如带id、createdAt的BaseEntity）
• 通用仓库接口（如BaseRepository）
• GraphQL通用标量类型、基础DTO
• 工具函数、常量配置

所有业务域库仅允许依赖@app/core，禁止域库之间直接依赖，从根源上避免循环依赖，同时减少重复代码。

用NX边界规则强制架构合规 #

在项目ESLint配置中启用NX的@nrwl/nx/enforce-module-boundaries规则，示例配置：

{
  "rules": {
    "@nrwl/nx/enforce-module-boundaries": [
      "error",
      {
        "allow": [],
        "depConstraints": [
          {
            "sourceTag": "domain:*",
            "onlyDependOnLibsWithTags": ["core", "domain:*"]
          },
          {
            "sourceTag": "core",
            "onlyDependOnLibsWithTags": []
          }
        ]
      }
    ]
  }
}

通过标签（tag）限制域库只能依赖核心库，防止随意跨域依赖导致的架构混乱。

域库内部分层，明确职责边界 #

每个业务域库内部按职责分层，避免代码耦合：

• domain/：存放实体、业务规则、仓库接口（核心业务逻辑，不依赖外部框架）
• infrastructure/：存放TypeORM仓库实现、数据库连接配置（框架依赖层，实现domain层接口）
• api/：存放GraphQL resolver、输入/输出DTO（对外暴露的API层）
• application/：存放用例（协调domain层和infrastructure层，处理业务流程）

分层后，库对外仅暴露api和application的接口，内部细节隐藏，进一步降低依赖面。

跨域实体关联的处理技巧 #

对于跨域关联（如expense关联customer），不要直接在实体中引用其他域的实体，而是：

1. 在expense实体中只存储customerId字段，用TypeORM的@Column而非@ManyToOne直接关联
2. 在GraphQL resolver中，通过DataLoader批量调用identity-domain的服务获取用户信息，避免N+1查询
3. 业务逻辑中，若需跨域数据，通过应用层服务调用（如ExpenseService注入CustomerService），而非直接操作实体

这样既保持了域的独立性，又能满足业务关联需求。

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