用途：规范业务逻辑入口点的代码组织方式，确保每个入口点独立成模块，适用于创建、修改、评审或整理业务逻辑入口点的场景。
主要能力与规则：每个命令处理器、查询处理器、用例各占一个模块；一个应用服务方法对应一个只含单个公共函数的应用服务模块。不得按领域实体类型分组入口点，例如不创建含 createUser、updateUser、findUserById、deleteUserById 方法的 UserService 类，也不创建打包全部预约操作的 ReservationUseCases 类，或导出同一实体多个入口函数的文件。模块应以其具体业务操作命名，如 create-reservation-command-handler、find-user-by-id-query-handler，而非 user-service、reservation-use-cases 等实体名；类或对象只能有一个作为入口点的公共函数，构造、依赖注入与私有辅助函数不计入。
理由：按实体分组会使文件随操作增加而膨胀，导致无关操作共享作用域与依赖、累积共享私有状态、难以隔离依赖，并产生合并冲突；独立模块让每个操作自包含、依赖显式、互不耦合。
使用方式（检测与改造）：查找含多个入口点的类、对象或文件及按实体分组的服务类、用例包、处理器集合；统计每个模块的公共入口点数量；检查模块名指向实体还是操作。新建入口点时新建模块，不向已有实体分组类添加方法；重构时把每个方法移入独立模块，赋予各自显式依赖，仅被单一入口点使用的私有辅助留在该模块，被多个入口点共享的辅助抽为独立模块。
限制：本资料仅给出规则与示例，未提供具体语言实现、工具链或自动化命令；具体代码内容因资料未完整给出而暂未提供。