首先对 cloudsso 全部的操作，画出一份时序图，时序图中包括每个操作步骤涉及的实体，这次改动的范围包括：创建用户、创建访问配置、多账号配置权限，这三个部分。

在重构前准备可靠的测试数据，有点类似 TDD（Test Drive Development）的思想，测试数据非常重要，用来验证你的对象参数是否正确，因为如果对产品模型理解错误，那么你构建的对象，测试数据一定是创建失败的

从哪里获取可靠的测试数据？自己随便造一些数据吗？

大部分情况下，我们自己随意造的数据，往往只能覆盖到比较小的功能点，类似单元测试，测试的意义是不大的；推荐根据云产品的最佳实践，根据产品文档提供的功能，将一个完整的 user story 涉及的数据作为测试数据，类似端到端测试，覆盖度更广

以 cloudsso 产品为例，其最佳应用场景是多账号多权限、同步AD，那么测试数据是这样构建的：

用户数据：

/* 云sso中的用户 */
variable "sso_users" {
  type = list(object({
    group_name   = string
    user_name    = string
    display_name = string
    comments     = string
  }))
  default = [
    {
      group_name   = "GG-Log"
      user_name    = "fandongfang"
      display_name = "fandongfang"
      comments     = "云sso用户"
    },
    {
      group_name   = "GG-Log"
      user_name    = "fandongfang2"
      display_name = "樊东方2"
      comments     = "云sso用户"
    },
    {
      group_name   = "GG-Security"
      user_name    = "weiliheng"
      display_name = "魏立恒"
      comments     = "云sso用户"
    },
    {
      group_name   = "GG-DO-Master"
      user_name    = "shenbinbin"
      display_name = "沈彬彬"
      comments     = "云sso用户"
  }]
}
Copy

权限数据：

/* 云sso中的访问配置 */
variable "sso_access" {
  type = map(object({
    sso_access_name    = string
    description        = string
    system_policy_list = list(string)
    custom_policy      = optional(string)
  }))

  default = {
    Administrator = {
      sso_access_name    = "Administrator"
      description        = "负责账号下的所有权限"
      system_policy_list = ["AdministratorAccess"]
    }
    FinaceAdmin = {
      sso_access_name = "FinaceAdmin"
      description     = "负责管理企业财务 （账单 付款 发票等），由GG-DO-Admin团队中部分核心成员扮演"
      system_policy_list = ["AliyunBSSFullAccess",
        "AliyunFinanceConsoleFullAccess",
      "AliyunCloudCommunicationFullAccess"]
    }
    SecurityAdmin = {
      sso_access_name = "SecurityAdmin"
      description     = "负责管理企业财务 （账单 付款 发票等），由GG-DO-Admin团队中部分核心成员扮演"
      system_policy_list = ["AliyunActionTrailFullAccess",
        "AliyunConfigFullAccess",
        "AliyunLogFullAccess",
        "AliyunOSSFullAccess",
        "ReadOnlyAccess",
      "AliyunBSSFullAccess"]
    }
    LogAdmin = {
      sso_access_name = "LogAdmin"
      description     = "负责组织下所有账号的日志采集分析工作"
      system_policy_list = ["AliyunLogFullAccess",
      "ReadOnlyAccess"]
    }
    BillingAdmin = {
      sso_access_name = "BillingAdmin"
      description     = "为兼容目前的老账号，负责管理企业财务 （账单 付款 发票等），由GG-DO-Admin团队中部分核心成员扮演"
      system_policy_list = ["AliyunBSSFullAccess",
        "AliyunFinanceConsoleFullAccess",
      "AliyunCloudCommunicationFullAccess"]
    }
  }
}

Copy

账号-权限-用户关系数据：

/* 云sso中的账号访问关系数据 账号(key)、用户（组）、权限 */
variable "sso_access_relation_name" {
  type = map(object({
    sso_relation_name = string
    description       = string
    deploy_user_group = list(object({
      target_type        = string
      target_name        = string
      deploy_access_list = list(string)
    }))
  }))

  default = {
    GG-Security = {
      sso_relation_name = "GG-Security-Rule"
      description       = "GG-Security 账号下的权限分配"
      deploy_user_group = [
        {
          target_type        = "User"
          target_name        = "fandongfang"
          deploy_access_list = ["SecurityAdmin"]
        },
        {
          target_type        = "Group"
          target_name        = "GG-Security"
          deploy_access_list = ["SecurityAdmin"]
      }]
    }
    GG-DO = {
      sso_relation_name = "GG-DO-Rule"
      description       = "GG-DO 账号下的权限分配"
      deploy_user_group = [
        {
          target_type        = "User"
          target_name        = "fandongfang"
          deploy_access_list = ["Administrator"]
      }]
    }
  }
}
Copy

将 "用户组" 看做一个实体对象（sso_users），类型是 list ，此list 中的对象拥有（group_name/user_name/display_name/comments）四个属性，从面向对象封装的角度看：

list 中的对象≈ Java 中的 PO（Persistant Object(持久对象))，与数据表中字段一一对应
sso_users ≈ Java 中的 BO（Bussiness Object(业务对象)), 是开发者根据产品的业务关系，在PO 上做的一层组合

variable "sso_users" {
  type = list(object({
    group_name   = string
    user_name    = string
    display_name = string
    comments     = string
  }))
Copy

这个结构在 cloudsso 上对应的页面是：

将”访问配置“看做一个实体对象（sso_access），类型是 map，其实这里设计为 list 和 map 都是可以的，选 map 是因为 Terraform 现在 for_each 只支持 map，不支持 list；另一个设计点，因为内置策略是可以为空的，所以使用了optional 关键字兼容可能存在的空指针（虽然目前还没有遇到过 terraform 关于空指针的报错，但作为Java开发者，必须得防范于未然）

variable "sso_access" {
  type = map(object({
    sso_access_name    = string
    description        = string
    system_policy_list = list(string)
    custom_policy      = optional(string)
  }))
}
Copy

这个结构在 cloudsso 上对应的页面是：

这是这次实践中遇到的最大难点了，由于”账号、用户、权限“ 这三个实体间的对应关系是多对多，为了准确的抽象出三者的关系，最终敲定的数据结构嵌套了三层，map 嵌套list(object)，object 中嵌套 list(string), 在 Java 中，其实这样的数据结构哪怕再嵌套5 6层，用 stream 处理起来也不过是一行代码的事情，但是由于 terraform 语法不支持stream，虽然也有内置的 flatten() 方法，但是处理起多层嵌套足以让人抓狂，最后如何解决这个嵌套问题的呢？我将在下一节中展开说明。

variable "sso_access_relation_name" {
  type = map(object({
    sso_relation_name = string
    description       = string
    deploy_user_group = list(object({
      target_type        = string
      target_name        = string
      deploy_access_list = list(string)
    }))
  }))
}
Copy

这个结构在 cloudsso 上对应的页面是：

完成这个开源项目后，如果再重新为一个产品写模版，我会按照这样的步骤：

• 先找测试数据，主要是参考我以往在阿里云 LandingZone 项目上使用的最佳实践数据，能串联起一个完整 user story 的数据最佳，并画出一个涵盖所有操作步骤的时序图
• 观察产品的设计，主要是思考各个实体间的对应关系（1对多，多对多)，其实当你观察到一定程度，自然而然就可以从页面上推测出产品后台的数据表设计
• 粗读这个产品对应的所有 resource，大部分情况下，一个 resource 可以对应一个实体，目前除了 ACK 的接口是我看过最多的，其他简单的云产品接口会在20个左右，初学者推荐从“资源管理”或者“云SSO”入手
• 最后一步，才是动手开发（这一步现在已经外包给 ChatGPT 做了）

这种开发方式的转变是很重要的，我以前写CRUD做“CV工程师”的时候，给自己带入的是一个搬砖工的角色，哪里需要就往哪里搬两块砖，不需要的地方也会搬两块砖，很多初级程序员刚入行的时候都是这样，根本不在乎自己的实现是否合理，只要搬来搬去能锻炼到肌肉💪🏻就行，如果恰巧功能也能堆出来，那就更是功德一件了。言至于此，不由的想起自己曾经在一个只有3个人的后端项目里强行引入flyway，在 Java8 刚支持Stream流式的时候没有机会也要创建机会，各种强行流式的种种行为，比较糟的是，后一个项目没有 code review，脑海中浮现出前同事们读我的模块时，脸上的痛苦面具......

当然这都是过去的事了，开发方式改变后，我现在扮演的是一个拿着图纸的包工头角色，更加关注每块砖之间的联系，是否合理，如果他不合理，我该如何修改他，每天在多个账号，几十个云产品，几百个微服务间来回踱步，让云上基础设施按照我手中最佳实践的图纸，稳定运行。

cloudsso 中创建访问配置，系统策略和自定义策略，使用的 resource 不同，所以在创建前，需要根据策略类型先分组再创建，为了实现分组的效果，使用了 locals 和 dynamic

locals {
  /* 访问控制的自定义策略和系统策略分组 */
  access_with_system = { for key, item in var.sso_access : key => item if null == item.custom_policy }
  access_with_custom = { for key, item in var.sso_access : key => item if null != item.custom_policy }
}


/* 云sso访问控制：系统策略  */
resource "alicloud_cloud_sso_access_configuration" "sso_system_access" {
  depends_on   = [data.alicloud_cloud_sso_service.open]
  directory_id = local.directory_id

  for_each                  = local.access_with_system
  access_configuration_name = each.value.sso_access_name
  description               = each.value.description

  dynamic "permission_policies" {
    for_each = each.value.system_policy_list
    content {
      permission_policy_type = "System"
      permission_policy_name = permission_policies.value
    }
  }
}
Copy

我理想中的最佳实现方式, 应该是类似这样的：
没错，引入默认方法，定义传参，一行解决，非常流式

/* 伪代码，仅供参考 */
resource "alicloud_cloud_sso_access_configuration" "sso_system_access" {
  var.sso_access.forEach(item => createAccess(item.name,item.description,item.system_policy_list)) 
}
Copy

上面已经提到，如果你的抽象设计中，将对象层级嵌套得越深，数据处理就越困难，以设计3 为例，因为嵌套了三层，所以在使用时，需要使用3层for循环进行取值

locals {
  sso_relation_configs = flatten([
    for account, relation in var.sso_access_relation_name : [
      for group_or_user in relation.deploy_user_group : [
        for role in group_or_user.deploy_access_list : {
          account_name       = account,
          relation_name      = relation.sso_relation_name,
          description        = relation.description,
          deploy_target_type = group_or_user.target_type,
          deploy_target_name = group_or_user.target_name,
          access_list        = role
        }
      ]
    ]
  ])

  /* 构建username 和 userid 的map, 通过 name 取ID */
  configurationMap = { for user in data.alicloud_cloud_sso_access_configurations.access_configurations.configurations :
  user.access_configuration_name => user.access_configuration_id }
  accountMap = { for user in data.alicloud_resource_manager_accounts.default.accounts :
  user.display_name => user.account_id }
}


/* 将分配的权限配置到指定的账号 */
resource "alicloud_cloud_sso_access_configuration_provisioning" "provisioning" {
  depends_on = [alicloud_cloud_sso_access_configuration.sso_custom_access, alicloud_cloud_sso_access_configuration.sso_system_access, alicloud_cloud_sso_group.sso_user_group]
  for_each = {
    for relation_config in local.sso_relation_configs :
    "${relation_config.account_name}:${relation_config.relation_name}:${relation_config.deploy_target_type}:${relation_config.deploy_target_name}" => relation_config
  }

  directory_id            = local.directory_id
  access_configuration_id = lookup(local.configurationMap, each.value.access_list, "tmp")
  target_id               = lookup(local.accountMap, each.value.account_name, "tmp")
  target_type             = "RD-Account"
}
Copy

多级嵌套下，我理想中多层级嵌套场景的最佳实现方式，应该是类似这样的：

resource "alicloud_cloud_sso_access_configuration_provisioning" "provisioning" {
	Optional.ofNullable(sso_access_relation_name)
            .map(List::stream)
            .map(obj -> {
                new relationDTO(getAccessConfigurationIdByName(obj.deploy_access_list(0)), 
                getTargrtIdByName(obj.target_name))
            })
            .collect(Collectors.toList());;
}
Copy

虽然这两类问题处理起来很是费劲，但本质是语言特性导致，我相信未来随着terraform语言的更新，都是可以解决的。