尧图网站建设 
后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载本篇指南以仓库内 doc/codebase/STRUCTURE.md 为骨架系统梳理 elsa-core.NET 工作流引擎的代码库组织方式顶层目录各自承担什么职责、应用入口如何装配、功能模块如何划分边界、测试与构建体系如何分层。读完本文你可以快速定位任意功能工作流、表达式、持久化、外部认证等的源码位置理解 Elsa 以模块为单位的演进方式并掌握从功能反查代码的导航方法。一、顶层布局速览一条主线、七个分区elsa-core 是一个大型多项目仓库顶层以src/为源码主体配合test/、build/、specs/等辅助分区。官方文档给出的顶层地图如下路径职责依据src/apps/可运行的应用程序宿主HostElsa.slnsrc/common/共享基础设施Elsa.slnsrc/modules/功能与领域模块Elsa.slnsrc/clients/API 客户端契约src/clients/Elsa.Api.Clienttest/单元、集成、组件与性能测试test/Directory.Build.propsbuild/NUKE 构建自动化build/Build.csspecs/功能规格与规划文档specs/012-weaver-grounding-tools/plan.md其中src/下的四个分区apps / common / modules / clients统一收编进根解决方案 Elsa.sln所有src项目共享 src/Directory.Build.props该文件继承仓库根的 Directory.Build.props 并引入 src/Fody.props同时将目标框架统一为net8.0;net9.0;net10.0。这意味着每个模块项目都不必重复声明框架版本与包版本——框架统一在这里收敛包版本则由仓库级 Directory.Packages.props 集中管理Central Package Management。二、应用入口src/apps/ 下的可运行宿主src/apps/是运行时runtime的入口层。从源码结构看src/apps当前包含四类宿主项目Elsa.Server.Web/面向服务端 API 场景的 Web 宿主内含 5 个.cs文件、4 个.json配置与多个.elsa工作流定义文件Elsa.ModularServer.Web/用于验证模块化组装能力的宿主9 个.cs文件、4 个.json演示如何按需挂载模块Elsa.Server.LoadBalancer/负载均衡场景的宿主示例Elsa.SamplePackage/用于验证打包与消费流程的示例项目。项目级配置在 src/apps/Directory.Build.props 中统一定义。从架构角度理解Elsa 的可执行能力几乎全部来自模块装配apps 项目本身很薄主要负责组合 Feature、配置中间件与启动 Web 服务器——这正是模块化运行时的体现。三、共享基础设施src/common/src/common/放置与具体业务无关的共享基础设施是各模块复用的底座。当前包含src/commonElsa.Api.Common/API 通用构件30 个.cs文件Elsa.Features/Feature 装配框架——整个 Elsa 的模块化加载机制依赖它模块通过实现/注册 Feature 来声明依赖并暴露能力Elsa.Mediator/进程内消息中介79 个.cs文件为模块解耦提供事件与命令通道Elsa.Testing.Shared/、Elsa.Testing.Shared.Component/、Elsa.Testing.Shared.Integration/供组件级与集成级测试复用的宿主与夹具。可以推断任何新模块想要获得可被宿主装配、可与其他模块解耦通信、可被测试托管的能力都需要依赖这里的Elsa.Features与Elsa.Mediator。四、功能与领域模块src/modules/仓库主体src/modules/是 elsa-core 的主体当前约 70 个模块项目按一个功能一个模块、一个模块一族项目的方式组织。模块族可归纳为几大类工作流核心Elsa.Workflows.Core510 个.cs、Elsa.Workflows.Management、Elsa.Workflows.Runtime、Elsa.Workflows.Api以及Elsa.Workflows.Runtime.Distributed/Elsa.Workflows.Runtime.Dashboard表达式与脚本Elsa.Expressions及 C# / JavaScript / Liquid / Python 各分支另有Elsa.Dsl.ElsaScriptElsa 自定义 DSL 与 ANTLR 语法持久化Elsa.Persistence.EFCore家族MySql / Oracle / PostgreSql / SqlServer / Sqlite 五类数据库适配以及新一代的Elsa.Persistence.VNext家族含 MongoDb / PostgreSql / SqlServer / Sqlite / Runtime / Relational连接与机密Elsa.Connections、Elsa.Secrets及其 EFCore 持久化分支外部认证Elsa.ExternalAuthentication、Elsa.ExternalAuthentication.OpenIdConnect、Elsa.ExternalAuthentication.Persistence.EFCore及各数据库适配、Elsa.ExternalAuthentication.Secrets其他领域能力Elsa.Http与Elsa.Http.Webhooks、Elsa.Scheduling、Elsa.Identity、Elsa.Tenants、Elsa.Labels、Elsa.UserTasks、Elsa.Alterations、Elsa.Bpmn、Elsa.AI.*Copilot / Host / Persistence、Elsa.Diagnostics.*OpenTelemetry / StructuredLogs / ConsoleLogs、Elsa.Resilience、Elsa.Caching、Elsa.KeyValues、Elsa.SasTokens、Elsa.Shells.Api等。模块内组织约定每个模块目录内部通常再按Contracts / Services / Endpoints / Stores / Extensions / Features分层详见下文命名与组织规则从而让契约—实现—端点—存储—装配一目了然。五、API 客户端契约src/clients/Elsa.Api.Clientsrc/clients/目前只有一个项目 Elsa.Api.Client236 个.cs文件。它的定位是向后兼容的客户端 DTO 与 HTTP 契约而不是持久化实体或服务端内部模型。也就是说服务端模块src/modules/*通过它定义对外暴露的请求/响应模型外部程序可以引用这个程序集直接获得强类型的工作流 API 客户端契约稳定是它的最高优先级——模块内部重构时只要不破坏Elsa.Api.Client的公开 DTO客户端消费者就不会感知。这也解释了 STRUCTURE.md 中Elsa.Api.Client允许放客户端 DTO禁止放持久化实体的边界要求。六、测试体系test/ 的四层金字塔test/目录按测试层级组织各层有独立的 test/Directory.Build.props 与 test/Directory.Build.targets层级目录代表项目单元测试test/unit/Elsa.Workflows.Core.UnitTests、Elsa.Activities.UnitTests、Elsa.Expressions.UnitTests等 40 个项目集成测试test/integration/Elsa.Workflows.IntegrationTests187 个.cs 71 个.json、Elsa.Http.IntegrationTests等组件测试test/component/Elsa.Workflows.ComponentTests141 个.cs性能测试test/performance/Elsa.Workflows.PerformanceTests其他test/workers/、test/TlsSmoke/后台工作进程与 TLS 冒烟验证配合共享测试库Elsa.Testing.Shared*每个被测模块几乎都有对应的UnitTests/IntegrationTests项目形成一模块一测试的镜像结构。七、构建自动化build/NUKEbuild/目录承载 NUKE 构建体系build/Build.cs、build/Build.CI.GitHubActions.cs、build/_build.csproj。仓库根部的 build.sh / build.ps1 / build.cmd 是 NUKE 引导入口。从结构推断构建任务还原、编译、打包 NuGet、运行测试都被集中定义在Build.cs中CIGitHub Actions通过 .github 下的工作流调用 NUKE 目标而非散落的 shell 脚本。八、规格与规划specs/specs/存放功能规格与实施计划每个功能一个编号目录典型的目录结构包含spec.md、plan.md、tasks.md、research.md、contracts/、checklists/等。例如 specs/012-weaver-grounding-tools/plan.md 即被 STRUCTURE.md 引用为 specs 分区的证据。这意味着 Elsa 的新功能遵循先有规格、再进源码的开发节奏阅读规格目录可以预知后续演进方向。九、入口点与端点发现以外部认证为例STRUCTURE.md 明确了两条重要的工程事实主运行时入口是src/apps/下的应用程序项目——真正Main方法所在模块本身不直接可运行端点发现endpoint discovery是模块化的——例如外部认证的 identity-link 端点集中位于 src/modules/Elsa.ExternalAuthentication/Endpoints/IdentityLinks/IdentityLinkEndpoints.cs。沿此线索可以在源码中验证外部认证如何被组装AddExternalAuthenticationServices扩展方法定义于 src/modules/Elsa.ExternalAuthentication/Extensions/ServiceCollectionExtensions.cs并通过 src/modules/Elsa.ExternalAuthentication/Features/ExternalAuthenticationFeature.cs 的 Feature 机制注册若要换成 EF Core 持久化实现则由 src/modules/Elsa.ExternalAuthentication.Persistence.EFCore/Extensions/ServiceCollectionExtensions.cs 提供可替换的注册。模块的 READMEsrc/modules/Elsa.ExternalAuthentication/README.md给出了完整的装配示例services.AddElsa(elsa { elsa.UseExternalAuthentication(feature { feature.ConfigureOptions options configuration.GetSection(ExternalAuthentication).BindExternalAuthenticationOptions(options); }); }); services.AddOpenIdConnectExternalAuthentication();从端点目录看src/modules/Elsa.ExternalAuthentication/Endpoints外部认证模块内部按职责拆出了多个端点组Broker/发起/回调/令牌交换/登出、IdentityLinks/身份链接、Sessions/、Descriptors/、Connections/、Previews/。这正好演示了端点发现模块化 端点按子域组织的组合拳要找某个 HTTP 端点的实现先锁定模块再按端点语义找对应子目录即可。十、模块边界什么东西应该放在哪里STRUCTURE.md 用一张边界表明确回答了一个模块设计中最常被问的问题——哪些代码属于哪个模块。原表完整如下边界属于这里绝不允许放这里Elsa.ExternalAuthenticationBroker 编排、契约、内存态存储、安全的 HTTP DTO特定协议提供方的行为Elsa.ExternalAuthentication.OpenIdConnectOIDC 回调与 provider 适配行为Elsa 用户授权策略Elsa.ExternalAuthentication.Persistence.EFCore持久化实体与 store 实现UI 展示Elsa.Api.Client向后兼容的客户端 DTO 与 HTTP 契约持久化实体从中可以提炼出三条通用原则协议与编排分离OpenIdConnect这类适配器只关心协议细节不得越界定义 Elsa 自身的授权策略持久化与展示分离EF Core 模块只产出 durable entities 与 storeUI 相关代码不得混入契约与实现分离Elsa.Api.Client作为对外契约层内部实体永远不能泄漏进来。这套边界不是纸面规则——仓库中外部认证的一个功能族 多数据库适配项目Elsa.ExternalAuthentication.Persistence.EFCore.MySql/Oracle/PostgreSql/SqlServer/Sqlite正是按此拆分的实际落地。以Elsa.ExternalAuthentication模块为例其职责限定为协议无关的 Broker 编排它组合部署安装的 provider 适配器、连接来源、未链接身份策略、权限授权来源、机密解析器、原子流存储与 Elsa 令牌签发但不保留 provider 令牌、不把外部声明当作 Elsa 权限除非显式配置的授权来源做了映射或约束——这与边界表完全一致。十一、命名与组织规则STRUCTURE.md 还固定了三条贯穿全仓库的工程规范PascalCase所有 C# 文件与公开类型一律使用 PascalCase 命名先功能、后分层模块按功能组织模块内部再按Contracts / Services / Endpoints / Stores等角色分层命名空间跟随文件夹使用文件级作用域file-scoped每个文件一个namespace声明且命名空间路径与物理目录保持一致。这些规则的执行依据见 .editorconfig代码风格与分析规则、src/Directory.Build.propsLangVersionlatest、Nullableenable、ImplicitUsingsenable以及仓库根 Directory.Build.props文档生成与分析模式、TreatWarningsAsErrorsfalse等。另外仓库还配套 IDE 级配置 Elsa.sln.DotSettings与命令行分析一起约束代码风格。十二、证据清单如何自行复核STRUCTURE.md 结尾给出的证据文件可作为读者进一步深入仓库的入口Elsa.sln顶层地图apps/common/modules 归属的直接依据src/modules/Elsa.ExternalAuthentication/Extensions/ServiceCollectionExtensions.csAddExternalAuthenticationServices组合外部认证的入口src/modules/Elsa.ExternalAuthentication.Persistence.EFCore/Extensions/ServiceCollectionExtensions.csEF Core 持久化的可选替换注册.editorconfig命名与风格规则的强制执行配置。总结一条从功能到代码的导航路径综合全文在 elsa-core 中定位任何功能的推荐路径是先看 specs/ 是否有该功能的规格与计划 → 在 src/modules/ 找到对应模块族 → 模块内按Contracts / Endpoints / Stores深入实现 → 到 src/clients/Elsa.Api.Client 核对对外契约 → 到 test/ 对应层级查看测试佐证 → 最后在 src/apps/ 看宿主如何装配该模块。沿着这条链路配合 STRUCTURE.md 的边界规则你可以在大型代码库中快速建立功能 → 模块 → 端点 → 契约 → 测试 → 宿主的完整心智地图。赞分享后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载相关推荐V8 仓库结构全解析从 src/ 源码布局到 docs/ 设计文档的导航指南V8 仓库结构全解析从 src/ 源码布局到 docs/ 设计文档的导航指南 本指南以 V8 仓库的目录结构为核心主线系统梳理 src/ 下各子系统的职责边语言运行时编译器JIT编译解释器内存管理vscode-cpptools代码导航继承层次结构vscode cpptools代码导航继承层次结构 1. 继承层次结构导航概述 在大型C/C项目开发中类Class与接口Interface的继承开发工具调试器Electron 源码目录结构完全指南解析 Chromium 宿主下的 src/electron 分层代码组织Electron 源码目录结构完全指南解析 Chromium 宿主下的 src/electron 分层代码组织 本文以 Electron 官方开发文档 sou桌面应用跨平台前端上一篇svg-sprite 性能优化SVGO压缩、缓存策略和构建速度提升下一篇Dillinger 仓库 Docker Expert 技能指南容器化、多阶段构建与生产部署的 AI Agent 专家知识体系创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Elsa Core 代码库结构全解析：src、test、build 与 specs 分层导航指南
后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载本篇指南以仓库内 doc/codebase/STRUCTURE.md 为骨架系统梳理 elsa-core.NET 工作流引擎的代码库组织方式顶层目录各自承担什么职责、应用入口如何装配、功能模块如何划分边界、测试与构建体系如何分层。读完本文你可以快速定位任意功能工作流、表达式、持久化、外部认证等的源码位置理解 Elsa 以模块为单位的演进方式并掌握从功能反查代码的导航方法。一、顶层布局速览一条主线、七个分区elsa-core 是一个大型多项目仓库顶层以src/为源码主体配合test/、build/、specs/等辅助分区。官方文档给出的顶层地图如下路径职责依据src/apps/可运行的应用程序宿主HostElsa.slnsrc/common/共享基础设施Elsa.slnsrc/modules/功能与领域模块Elsa.slnsrc/clients/API 客户端契约src/clients/Elsa.Api.Clienttest/单元、集成、组件与性能测试test/Directory.Build.propsbuild/NUKE 构建自动化build/Build.csspecs/功能规格与规划文档specs/012-weaver-grounding-tools/plan.md其中src/下的四个分区apps / common / modules / clients统一收编进根解决方案 Elsa.sln所有src项目共享 src/Directory.Build.props该文件继承仓库根的 Directory.Build.props 并引入 src/Fody.props同时将目标框架统一为net8.0;net9.0;net10.0。这意味着每个模块项目都不必重复声明框架版本与包版本——框架统一在这里收敛包版本则由仓库级 Directory.Packages.props 集中管理Central Package Management。二、应用入口src/apps/ 下的可运行宿主src/apps/是运行时runtime的入口层。从源码结构看src/apps当前包含四类宿主项目Elsa.Server.Web/面向服务端 API 场景的 Web 宿主内含 5 个.cs文件、4 个.json配置与多个.elsa工作流定义文件Elsa.ModularServer.Web/用于验证模块化组装能力的宿主9 个.cs文件、4 个.json演示如何按需挂载模块Elsa.Server.LoadBalancer/负载均衡场景的宿主示例Elsa.SamplePackage/用于验证打包与消费流程的示例项目。项目级配置在 src/apps/Directory.Build.props 中统一定义。从架构角度理解Elsa 的可执行能力几乎全部来自模块装配apps 项目本身很薄主要负责组合 Feature、配置中间件与启动 Web 服务器——这正是模块化运行时的体现。三、共享基础设施src/common/src/common/放置与具体业务无关的共享基础设施是各模块复用的底座。当前包含src/commonElsa.Api.Common/API 通用构件30 个.cs文件Elsa.Features/Feature 装配框架——整个 Elsa 的模块化加载机制依赖它模块通过实现/注册 Feature 来声明依赖并暴露能力Elsa.Mediator/进程内消息中介79 个.cs文件为模块解耦提供事件与命令通道Elsa.Testing.Shared/、Elsa.Testing.Shared.Component/、Elsa.Testing.Shared.Integration/供组件级与集成级测试复用的宿主与夹具。可以推断任何新模块想要获得可被宿主装配、可与其他模块解耦通信、可被测试托管的能力都需要依赖这里的Elsa.Features与Elsa.Mediator。四、功能与领域模块src/modules/仓库主体src/modules/是 elsa-core 的主体当前约 70 个模块项目按一个功能一个模块、一个模块一族项目的方式组织。模块族可归纳为几大类工作流核心Elsa.Workflows.Core510 个.cs、Elsa.Workflows.Management、Elsa.Workflows.Runtime、Elsa.Workflows.Api以及Elsa.Workflows.Runtime.Distributed/Elsa.Workflows.Runtime.Dashboard表达式与脚本Elsa.Expressions及 C# / JavaScript / Liquid / Python 各分支另有Elsa.Dsl.ElsaScriptElsa 自定义 DSL 与 ANTLR 语法持久化Elsa.Persistence.EFCore家族MySql / Oracle / PostgreSql / SqlServer / Sqlite 五类数据库适配以及新一代的Elsa.Persistence.VNext家族含 MongoDb / PostgreSql / SqlServer / Sqlite / Runtime / Relational连接与机密Elsa.Connections、Elsa.Secrets及其 EFCore 持久化分支外部认证Elsa.ExternalAuthentication、Elsa.ExternalAuthentication.OpenIdConnect、Elsa.ExternalAuthentication.Persistence.EFCore及各数据库适配、Elsa.ExternalAuthentication.Secrets其他领域能力Elsa.Http与Elsa.Http.Webhooks、Elsa.Scheduling、Elsa.Identity、Elsa.Tenants、Elsa.Labels、Elsa.UserTasks、Elsa.Alterations、Elsa.Bpmn、Elsa.AI.*Copilot / Host / Persistence、Elsa.Diagnostics.*OpenTelemetry / StructuredLogs / ConsoleLogs、Elsa.Resilience、Elsa.Caching、Elsa.KeyValues、Elsa.SasTokens、Elsa.Shells.Api等。模块内组织约定每个模块目录内部通常再按Contracts / Services / Endpoints / Stores / Extensions / Features分层详见下文命名与组织规则从而让契约—实现—端点—存储—装配一目了然。五、API 客户端契约src/clients/Elsa.Api.Clientsrc/clients/目前只有一个项目 Elsa.Api.Client236 个.cs文件。它的定位是向后兼容的客户端 DTO 与 HTTP 契约而不是持久化实体或服务端内部模型。也就是说服务端模块src/modules/*通过它定义对外暴露的请求/响应模型外部程序可以引用这个程序集直接获得强类型的工作流 API 客户端契约稳定是它的最高优先级——模块内部重构时只要不破坏Elsa.Api.Client的公开 DTO客户端消费者就不会感知。这也解释了 STRUCTURE.md 中Elsa.Api.Client允许放客户端 DTO禁止放持久化实体的边界要求。六、测试体系test/ 的四层金字塔test/目录按测试层级组织各层有独立的 test/Directory.Build.props 与 test/Directory.Build.targets层级目录代表项目单元测试test/unit/Elsa.Workflows.Core.UnitTests、Elsa.Activities.UnitTests、Elsa.Expressions.UnitTests等 40 个项目集成测试test/integration/Elsa.Workflows.IntegrationTests187 个.cs 71 个.json、Elsa.Http.IntegrationTests等组件测试test/component/Elsa.Workflows.ComponentTests141 个.cs性能测试test/performance/Elsa.Workflows.PerformanceTests其他test/workers/、test/TlsSmoke/后台工作进程与 TLS 冒烟验证配合共享测试库Elsa.Testing.Shared*每个被测模块几乎都有对应的UnitTests/IntegrationTests项目形成一模块一测试的镜像结构。七、构建自动化build/NUKEbuild/目录承载 NUKE 构建体系build/Build.cs、build/Build.CI.GitHubActions.cs、build/_build.csproj。仓库根部的 build.sh / build.ps1 / build.cmd 是 NUKE 引导入口。从结构推断构建任务还原、编译、打包 NuGet、运行测试都被集中定义在Build.cs中CIGitHub Actions通过 .github 下的工作流调用 NUKE 目标而非散落的 shell 脚本。八、规格与规划specs/specs/存放功能规格与实施计划每个功能一个编号目录典型的目录结构包含spec.md、plan.md、tasks.md、research.md、contracts/、checklists/等。例如 specs/012-weaver-grounding-tools/plan.md 即被 STRUCTURE.md 引用为 specs 分区的证据。这意味着 Elsa 的新功能遵循先有规格、再进源码的开发节奏阅读规格目录可以预知后续演进方向。九、入口点与端点发现以外部认证为例STRUCTURE.md 明确了两条重要的工程事实主运行时入口是src/apps/下的应用程序项目——真正Main方法所在模块本身不直接可运行端点发现endpoint discovery是模块化的——例如外部认证的 identity-link 端点集中位于 src/modules/Elsa.ExternalAuthentication/Endpoints/IdentityLinks/IdentityLinkEndpoints.cs。沿此线索可以在源码中验证外部认证如何被组装AddExternalAuthenticationServices扩展方法定义于 src/modules/Elsa.ExternalAuthentication/Extensions/ServiceCollectionExtensions.cs并通过 src/modules/Elsa.ExternalAuthentication/Features/ExternalAuthenticationFeature.cs 的 Feature 机制注册若要换成 EF Core 持久化实现则由 src/modules/Elsa.ExternalAuthentication.Persistence.EFCore/Extensions/ServiceCollectionExtensions.cs 提供可替换的注册。模块的 READMEsrc/modules/Elsa.ExternalAuthentication/README.md给出了完整的装配示例services.AddElsa(elsa { elsa.UseExternalAuthentication(feature { feature.ConfigureOptions options configuration.GetSection(ExternalAuthentication).BindExternalAuthenticationOptions(options); }); }); services.AddOpenIdConnectExternalAuthentication();从端点目录看src/modules/Elsa.ExternalAuthentication/Endpoints外部认证模块内部按职责拆出了多个端点组Broker/发起/回调/令牌交换/登出、IdentityLinks/身份链接、Sessions/、Descriptors/、Connections/、Previews/。这正好演示了端点发现模块化 端点按子域组织的组合拳要找某个 HTTP 端点的实现先锁定模块再按端点语义找对应子目录即可。十、模块边界什么东西应该放在哪里STRUCTURE.md 用一张边界表明确回答了一个模块设计中最常被问的问题——哪些代码属于哪个模块。原表完整如下边界属于这里绝不允许放这里Elsa.ExternalAuthenticationBroker 编排、契约、内存态存储、安全的 HTTP DTO特定协议提供方的行为Elsa.ExternalAuthentication.OpenIdConnectOIDC 回调与 provider 适配行为Elsa 用户授权策略Elsa.ExternalAuthentication.Persistence.EFCore持久化实体与 store 实现UI 展示Elsa.Api.Client向后兼容的客户端 DTO 与 HTTP 契约持久化实体从中可以提炼出三条通用原则协议与编排分离OpenIdConnect这类适配器只关心协议细节不得越界定义 Elsa 自身的授权策略持久化与展示分离EF Core 模块只产出 durable entities 与 storeUI 相关代码不得混入契约与实现分离Elsa.Api.Client作为对外契约层内部实体永远不能泄漏进来。这套边界不是纸面规则——仓库中外部认证的一个功能族 多数据库适配项目Elsa.ExternalAuthentication.Persistence.EFCore.MySql/Oracle/PostgreSql/SqlServer/Sqlite正是按此拆分的实际落地。以Elsa.ExternalAuthentication模块为例其职责限定为协议无关的 Broker 编排它组合部署安装的 provider 适配器、连接来源、未链接身份策略、权限授权来源、机密解析器、原子流存储与 Elsa 令牌签发但不保留 provider 令牌、不把外部声明当作 Elsa 权限除非显式配置的授权来源做了映射或约束——这与边界表完全一致。十一、命名与组织规则STRUCTURE.md 还固定了三条贯穿全仓库的工程规范PascalCase所有 C# 文件与公开类型一律使用 PascalCase 命名先功能、后分层模块按功能组织模块内部再按Contracts / Services / Endpoints / Stores等角色分层命名空间跟随文件夹使用文件级作用域file-scoped每个文件一个namespace声明且命名空间路径与物理目录保持一致。这些规则的执行依据见 .editorconfig代码风格与分析规则、src/Directory.Build.propsLangVersionlatest、Nullableenable、ImplicitUsingsenable以及仓库根 Directory.Build.props文档生成与分析模式、TreatWarningsAsErrorsfalse等。另外仓库还配套 IDE 级配置 Elsa.sln.DotSettings与命令行分析一起约束代码风格。十二、证据清单如何自行复核STRUCTURE.md 结尾给出的证据文件可作为读者进一步深入仓库的入口Elsa.sln顶层地图apps/common/modules 归属的直接依据src/modules/Elsa.ExternalAuthentication/Extensions/ServiceCollectionExtensions.csAddExternalAuthenticationServices组合外部认证的入口src/modules/Elsa.ExternalAuthentication.Persistence.EFCore/Extensions/ServiceCollectionExtensions.csEF Core 持久化的可选替换注册.editorconfig命名与风格规则的强制执行配置。总结一条从功能到代码的导航路径综合全文在 elsa-core 中定位任何功能的推荐路径是先看 specs/ 是否有该功能的规格与计划 → 在 src/modules/ 找到对应模块族 → 模块内按Contracts / Endpoints / Stores深入实现 → 到 src/clients/Elsa.Api.Client 核对对外契约 → 到 test/ 对应层级查看测试佐证 → 最后在 src/apps/ 看宿主如何装配该模块。沿着这条链路配合 STRUCTURE.md 的边界规则你可以在大型代码库中快速建立功能 → 模块 → 端点 → 契约 → 测试 → 宿主的完整心智地图。赞分享后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载相关推荐V8 仓库结构全解析从 src/ 源码布局到 docs/ 设计文档的导航指南V8 仓库结构全解析从 src/ 源码布局到 docs/ 设计文档的导航指南 本指南以 V8 仓库的目录结构为核心主线系统梳理 src/ 下各子系统的职责边语言运行时编译器JIT编译解释器内存管理vscode-cpptools代码导航继承层次结构vscode cpptools代码导航继承层次结构 1. 继承层次结构导航概述 在大型C/C项目开发中类Class与接口Interface的继承开发工具调试器Electron 源码目录结构完全指南解析 Chromium 宿主下的 src/electron 分层代码组织Electron 源码目录结构完全指南解析 Chromium 宿主下的 src/electron 分层代码组织 本文以 Electron 官方开发文档 sou桌面应用跨平台前端上一篇svg-sprite 性能优化SVGO压缩、缓存策略和构建速度提升下一篇Dillinger 仓库 Docker Expert 技能指南容器化、多阶段构建与生产部署的 AI Agent 专家知识体系创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考