更新 llms-full.txt

llms-full.txt

@@ -7,13 +7,13 @@
 ### **2. TOCO 设计元素:**
 #### **2.1 模块 (Module)**
 - **定义与用途:** 在TOCO中，我们将系统领域细分为具体的模块，映射为Java工程中的module。这些模块代表了系统的叶子子域，每个模块负责特定的功能。模块划分有助于系统的可维护性和可扩展性，并能提高开发效率和代码质量
-- **关键配置:** 名称(小写英文字母+下划线，如meeting,user_detail,禁止加任何固定后缀)，描述
+- **关键配置:** 名称(小写英文字母+下划线，如meeting,user_detail,禁止加任何固定后缀,全局唯一)，描述
 - **与其他元素关系:**  下面的每种设计元素都属于一个模块
 - **代码产物：** 每个Module会单独生成一个Java Module：项目路径/modules/模块名，内部采用了entrance、service、manager、persist、common分层结构
 
 #### **2.2 枚举 (Enum)**
 - **定义与用途:** Enum用来表达一些常量值的集合，可被其他模块使用，可被用来做为字段的类型
-- **关键属性/配置:**  名称(以_enum结尾)，枚举值列表(全大写字母+下划线)
+- **关键属性/配置:**  名称(以_enum结尾,全局唯一)，枚举值列表(全大写字母+下划线)
 - **与其他元素关系:**  枚举可以作为其他对象（Entity、Dto、Vo、Bto、Qto、Eo)的字段类型使用。
 - **Enum设计元素的表达:**
     - 以Json格式表达，json schema 定义如下
@@ -43,7 +43,7 @@
     - **修改建议：** 不建议修改
 #### **2.3 值对象 (Eo)**
 - **定义与用途:** EO为一种POJO对象结构，可被其他模块使用，可被用来做为实体字段的类型。
-- **关键属性/配置:** 名称(以_eo结尾)。EO的字段类型只能为基本类型（含List）、EO、Enum，其他类型不允许。
+- **关键属性/配置:** 名称(以_eo结尾,全局唯一)。EO的字段类型只能为基本类型（含List）、EO、Enum，其他类型不允许。
 - **与其他元素关系:** 可以作为其他对象（Entity、Dto、Vo、Bto、Qto)的字段类型使用，同时一个Eo中可以嵌套其他EO作为字段类型。
 - **Eo设计元素的表达:**
     - 以Json格式表达，Json Schema定义及如下
@@ -135,7 +135,7 @@
 #### **2.6 数据传输对象 (DTO)**
 - **定义与用途:** 在TOCO中，DTO表达某个Entity为基本，通过外键关系不断关联多个Entity的数据结构。DTO还隐式表达了数据的取数拼装，这种拼装符合外键关系。往往被当做RPC的返回值、或读方案的返回值使用，不建议把DTO作为入参。注意DTO不能作为HTTP API的返回值。DTO分为BaseDTO和普通DTO，BaseDTO派生自Entity，包含Entity的所有字段，每个Entity有且仅有一个BaseDTO；普通DTO派生自BaseDTO，包含BaseDTO的所有字段，且可以增加扩展字段或自定义字段
 - **如何创建/生成:**  对于每个Entity，TOCO会自动生成一个BaseDTO，命名为${Entity名字}BaseDto，如UserBaseDto，该BaseDTO包含了Entity的全部字段。除了BaseDTO，其他的DTO均需要手动以BaseDTO为根来创建。在TOCO中，必须要先判断需要的DTO是否为BaseDTO，如果是BaseDTO，则可通过Entity名称获取BaseDTO；如果不是BaseDTO，则需要通过DTO要表达的信息来创建DTO，如：会议及其议程信息。
-- **关键配置:**  名称(BaseDTO以BaseDto结尾，其他DTO以Dto结尾)、根Entity、字段列表。DTO中的字段分为三种：a.继承Entity或BaseDTO的字段，和Entity及BaseDTO的字段类型一样；b.扩展字段，含正向替换和反向注入字段，类型为DTO或List<DTO>;c.自定义字段，类型为基本类型、Eo、Enum、DTO类型。BaseDTO中一般包含Entity的全部字段,DTO中一般包含BaseDTO中的全部字段，不进行字段裁剪，可以根据外键关系扩展其他Entity(详见**字段扩展方式**)，在明确无法扩展外部Entity的情况下，可增加对应的自定义字段。
+- **关键配置:**  名称(BaseDTO以BaseDto结尾，其他DTO以Dto结尾,全局唯一)、根Entity、字段列表。DTO中的字段分为三种：a.继承Entity或BaseDTO的字段，和Entity及BaseDTO的字段类型一样；b.扩展字段，含正向替换和反向注入字段，类型为DTO或List<DTO>;c.自定义字段，类型为基本类型、Eo、Enum、DTO类型。BaseDTO中一般包含Entity的全部字段,DTO中一般包含BaseDTO中的全部字段，不进行字段裁剪，可以根据外键关系扩展其他Entity(详见**字段扩展方式**)，在明确无法扩展外部Entity的情况下，可增加对应的自定义字段。
 - **字段扩展方式:**TOCO定义了一个DTO组装方法，适用于DTO通过外键关系替换/注入对应Entity的信息，对象化表达有外键关系的Entity信息。只要存在外键关系且满足以下条件即可扩展：a.对于正向替换：当前实体存在指向其他实体的外键字段；b.对于反向注入：其他实体存在指向当前实体的外键字段。
   例如：有两个Entity
 ```
@@ -283,7 +283,7 @@ DateTime endTime； //会议结束时间
 
 #### **2.7 视图对象 (VO)**
 - **定义与用途:** 在TOCO中，VO表达某个BaseDTO(如果用户指明派生源，也可使用其他DTO)为派生源，通过外键关系不断关联多个BaseDTO的数据结构。VO用于在视图层与前端之间进行数据传输，往往被当做HTTP API的返回值、或读方案的返回值使用，由服务端返回至前端。注意VO不能作为RPC的返回值。
-- **关键配置:**  名称(以Vo结尾)、根Entity、派生源、字段列表。VO中的字段分为三种：a.继承DTO的字段，如果DTO中的字段为基础类型或EO、Enum，则VO中的继承字段和和DTO的字段类型一样，如果DTO中的字段为DTO或List<DTO>类型，则继承字段为字段对应的DTO类型派生出的VO或List<VO>类型；b.扩展字段，含正向替换和反向注入字段，类型为VO或List<VO>;c.自定义字段，类型为基本类型或VO类型。VO中的字段来源于DTO，可以根据页面需要将无用字段进行裁剪，可以根据外键关系扩展其他BaseDto(详见**字段扩展方式**)。如果在派生源中没有合适字段，且明确无法通过外键扩展外部BaseDto的情况下，可增加对应的自定义字段
+- **关键配置:**  名称(以Vo结尾,全局唯一)、根Entity、派生源、字段列表。VO中的字段分为三种：a.继承DTO的字段，如果DTO中的字段为基础类型或EO、Enum，则VO中的继承字段和和DTO的字段类型一样，如果DTO中的字段为DTO或List<DTO>类型，则继承字段为字段对应的DTO类型派生出的VO或List<VO>类型；b.扩展字段，含正向替换和反向注入字段，类型为VO或List<VO>;c.自定义字段，类型为基本类型或VO类型。VO中的字段来源于DTO，可以根据页面需要将无用字段进行裁剪，可以根据外键关系扩展其他BaseDto(详见**字段扩展方式**)。如果在派生源中没有合适字段，且明确无法通过外键扩展外部BaseDto的情况下，可增加对应的自定义字段
 - **继承字段类型转换:**  VO只和其派生源VO之间有转换关系。当一个VO派生自某个DTO，且该VO继承了派生源DTO中的DTO类型字段(假设为DTO-A)，此时VO中对应的继承字段类型必须为VO(假设为VO-A)，且**VO-A也必须派生自DTO-A**，如此才能维持VO和DTO之间的转换关系
 - **与DTO的区别 (在TOCO语境下): **DTO用于服务层传输，通常作为RPC的返回值，与数据模型更近，复用性较强；VO用于视图层传输，通常作为API的返回值，与UI展示更为接近，可裁剪掉不需要的DTO中的冗余字段，复用性较弱。
 - **如何创建/生成:** VO通常由某个BaseDTO以及外键关系为基础派生，也可以直接创建和DTO无关、内部全为自定义字段的VO（尽量少用，只为应对某些特殊页面，需要组装一组完全无关的返回数据的场景）。
@@ -648,7 +648,7 @@ DateTime endTime； //会议结束时间
 - **定义与用途:** 在TOCO中，针对DTO和VO，读方案描述了如何基于查询对象从数据库获取DTO和VO列表数据，主要提供了两个能力
     - 根据查询条件，返回符合条件的DTO或VO的id列表
     - 根据字段过滤条件，对DTO和VO的列表字段数据进行过滤
-- **关键配置:**  名称(小写字母+下划线，不要以read_plan结尾)、返回结构(DTO/VO，一个读方案**不能**同时返回多种DTO或VO)、查询条件的自然语言描述、是否生成计数方法、排序字段（如果选择不分页，则不需要）、过滤字段以及过滤条件。
+- **关键配置:**  名称(小写字母+下划线，不要以read_plan结尾,全局唯一)、返回结构(DTO/VO，一个读方案**不能**同时返回多种DTO或VO)、查询条件的自然语言描述、是否生成计数方法、排序字段（如果选择不分页，则不需要）、过滤字段以及过滤条件。
 - **与RPC、代码的关系:** 对于每一个返回DTO的读方案，TOCO会为每种分页方式自动生成一个RPC方法，其参数为对应的QTO，返回值为DTO列表；如果选择了生成计数方法，则还会生成一个RPC，参数为QTO，返回值为符合条件的DTO数量。同样，对于每一个返回VO的读方案，TOCO会自动生成一个Java方法，其参数为对应的QTO，返回值为VO列表，方法内部逻辑已经由TOCO完全实现;如果选择了生成计数方法，则还会生成一个count方法，参数为QTO，返回值为符合条件的DTO数量，方法内部逻辑已经由TOCO完全实现
 - **如何创建/生成:** 在创建读方案时，必须先调用工具创建或选择现有的**一种**DTO或VO作为返回值类型，然后再定义查询条件的自然语言描述（如：根据用户姓名、年龄、学校名称，查询用户列表），分页方式、是否生成计数方法、排序字段等。
 - **排序** 对于返回列表数据的排序，排序规则和SQL的排序类似(通过指定字段以及升序|降序，字段可以组合；ReadPlan支持有**两种**方式：
@@ -901,7 +901,7 @@ DateTime endTime； //会议结束时间
 - **与API的关系:** QTO通常可作为API的参数，API接收到参数后可直接透传给内部的RPC进行调用
 #### **2.11 写方案 (WritePlan)**
 - **定义与用途:** TOCO针对写场景定义了一种写方案，所有对数据库的写操作都只能通过写方案实现。写方案包含了对数据库表的写操作。每个写方案只能操作一个聚合内部的表，同时对一个聚合内表的操作尽量合并至一个写方案中（根据复用性、内聚性等方面具体情况具体分析）。注意写方案可以一次操作聚合内的多张表，如location和storey是同一个聚合，并且location和storey是**1:N**关系，location是父对象（聚合根），storey是子对象，那么我们可以创建一个写方案，同时更新单个聚合根location中的信息，以及操作其下的子表storey**列表**信息，如新增、删除、修改storey等；也可以创建一个写方案单独更新单个子表storey对象信息。
-- **关键配置:**  名称(小写字母+下划线，不要以write_plan结尾)，操作的聚合，聚合内的实体和字段，对每个实体的操作类型：CREATE（创建**单个**实体），UPDATE(更新**单个**实体), DELETE(删除**单个**实体), CREATE_ON_DUPLICATE_UPDATE(创建或者更新**单个**实体),FULL_MERGE( 批量更新**列表**数据，根据传入的列表数据，一条一条执行CREATE_ON_DUPLICATE_UPDATE的操作；并且删除掉老的列表中不在传入列表数据中的部分), PARTIAL_MERGE(批量更新**列表**数据，根据传入的列表数据，一条一条执行)
+- **关键配置:**  名称(小写字母+下划线，不要以write_plan结尾,全局唯一)，操作的聚合，聚合内的实体和字段，对每个实体的操作类型：CREATE（创建**单个**实体），UPDATE(更新**单个**实体), DELETE(删除**单个**实体), CREATE_ON_DUPLICATE_UPDATE(创建或者更新**单个**实体),FULL_MERGE( 批量更新**列表**数据，根据传入的列表数据，一条一条执行CREATE_ON_DUPLICATE_UPDATE的操作；并且删除掉老的列表中不在传入列表数据中的部分), PARTIAL_MERGE(批量更新**列表**数据，根据传入的列表数据，一条一条执行)
 - **与RPC的关系:** 对于每一个写方案，TOCO会自动生成一个RPC方法，其参数为写方案对应的BTO，返回值为本次操作的聚合根实体的主键值，内部只实现了对当前聚合的数据库操作
 - **与聚合的关系:** 每个聚合下可以定义多个写方案，但每个写方案只能操作一个聚合内的表，无法同时操作多个聚合内的表
 - **如何创建/生成:** 创建写方案时需要先选定对应的聚合，以及要操作的聚合内部的实体，然后确定对每个实体的具体操作类型
@@ -1092,7 +1092,7 @@ requestParams为请求参数列表，response为返回结构，requestParams中
 #### **2.14 应用程序接口 (API)**
 - **定义与用途:** 在TOCO中，API用于定义对外暴露的HTTP接口
 - **如何创建/生成:** API一般为通过TOCO创建，需指定具体的参数和返回值等
-- **关键配置:**  uri(加粗展示，一般为/api/${moduleName}/xxx，如/api/user/create。如果用户有特殊命名规则的话以用户要求为准)、类名(以Controller结尾)、方法名、请求参数、返回值
+- **关键配置:**  uri(加粗展示，一般为/api/${moduleName}/xxx，如/api/user/create,全局唯一。如果用户有特殊命名规则的话以用户要求为准)、类名(以Controller结尾)、方法名、请求参数、返回值
 - **参数类型:**  API的参数**只能**为QTO、BTO、Enum、基本类型，可为单值或列表。注意如果是对象类型，则优先使用QTO、BTO作为参数。**禁止使用**DTO、EO和自定义结构如Object
 - **返回值类型:**  TOCO的API运行在自己的Java脚手架中，脚手架会自动对API的返回值做一层对象包装（code、message、data）。所以在TOCO中，API的返回值无需考虑返回码和错误信息，只需考虑返回的数据本身。TOCO中API的返回值**只能**为VO、Enum、基本类型,可为单值或列表，**禁止使用**DTO、QTO、BTO、EO、自定义结构如Object作为返回值。注意如果是对象类型，则优先使用VO作为返回值。
 - **TOCO中json结构描述:** 在TOCO中，API使用一个json结构表示，示例如下：