在第1章中，我们已对DSL相关基础概念进行了简要介绍。尽管笔者已尽量简化表述，但仍涉及词法分析、语法分析等相对专业的内容。鉴于这些概念的重要性，本章将对其进行简明阐释。之所以不深入展开，主要基于两点考虑：其一，循序渐进的讲解方式更符合知识传递规律；其二，缺乏案例支撑的抽象概念易增加理解难度，而现阶段引入复杂细节尚不具备充分条件。因此，笔者计划在后续章节结合代码案例，对这些概念进行更深入的剖析。
前文将DSL划分为内部DSL与外部DSL两类，语言工作台因实际使用率较低暂不纳入讨论范围。这两类DSL的差异不仅体现在是否基于通用语言实现，其构成要素也存在显著区别。基于此，本章将以自顶向下的视角，重点阐述两类DSL的架构特征。需要说明的是，文中的架构描述并非行业标准，而是基于笔者个人实践经验的理解。事实上，不同技术人员对DSL架构的认知可能因知识背景和实践经验的差异而有所不同，建议读者在实际应用中灵活参考。
图 2.1展示了外部DSL的构成要素，可将其视为外部DSL的逻辑架构。其构成要素可进一步细化为“DSL脚本”和“DSL编译器”两部分，二者并非独立存在，而是存在由上至下的单向依赖关系。从用户视角出发，可将这两部分理解为DSL的前端（脚本层）和后端（编译器层），而基于编译原理的理论划分则有所不同，后文将详细阐述。
图 2.1中，部分元素以虚线表示，部分以实线表示。其中，虚线标识的元素为可选组件，实线标识的元素为核心组件。该架构图所呈现的是完整的外部DSL逻辑视图，适用于自定义语法的场景，实际落地时需根据目标DSL的形态和特性动态选择组件。例如：
- 若选择JSON作为DSL脚本格式，可通过Jackson等第三方类库直接将脚本转换为语义模型，无需自行开发词法分析器、语法分析器和语义模型构建器。
- 若无需生成目标代码，代码生成器组件可省略。
图 2.1中的语义模型构建器是前文未提及的组件，其核心功能为创建语义模型。通常的实现路径是：在语法分析阶段先构建抽象语法树（Abstract Syntax Tree，AST），随后通过遍历AST逐步构建语义模型。需要注意的是，AST构建属于语法分析的范畴，而语义模型构建器的职责是基于AST中的结构化信息，完成语义模型的实例化或执行逻辑编排。
对于通用编程语言的编译器，业界通常将其划分为“前端（Front End）”与“后端（Back End）”两部分。前端负责对源代码进行词法分析、语法分析，并构建中间表示形式（如抽象语法树AST或三地址代码）；后端则以中间表示为输入，生成目标机器语言（如针对x86、ARM架构的指令集）。
相比之下，DSL的编译器架构可进行简化。若需划分前后端，建议以AST为分界点：
- 前端。包含词法分析器、语法分析器，核心任务是将文本格式的DSL脚本转换为AST。
- 后端。以AST为输入，包含语义模型构建器、代码生成器等组件，负责语义处理和目标产物生成。
在此划分体系下，语义模型构建器属于后端组件，其输出为语义模型——这可能直接作为最终产物（如配置数据、执行逻辑），也可能作为代码生成器的输入。若DSL需要生成目标代码（如Java、Python等），则代码生成器同样属于后端。
需强调的是，这种划分方式仅针对编译器内部架构，与前文基于用户视角的“前端（DSL脚本）-后端（DSL编译器）”划分维度不同。在实际设计中，应根据DSL的应用场景灵活调整组件边界，避免过度工程化。
从另一视角审视外部DSL编译器的工作流程，具体如图 2.2所示。
DSL源代码被读取到编译器后，通常会经历词法分析（Lexical Analysis）、语法分析（Syntax Analysis）、语义模型构建和代码生成四个过程，但并非所有环节都是必需的。尽管本文未将语义分析作为独立环节，但其作为编译过程的重要步骤，通常伴随语法分析进行，或作为语义模型构建环节的子环节。需注意的是，上述四个流程是一种逻辑抽象，类似于微服务架构中的分层（如数据访问层、业务逻辑层），体现了对代码的责任划分。从外部视角看，编译器表现为单一实体，其输入为DSL脚本，输出可为语义模型实例、业务操作结果或生成的代码。此外，各环节并非完全呈线性输入/输出关系：词法分析与语法分析具有明确的输出/输入依赖，而语义模型构建与语法分析可能并行执行，具体取决于目标DSL的结构形态和复杂度。
了解了DSL编译器的基本组成和工作流程后，接下来的让我们对其中的重点组件进行更详细的解释，请读者移步下一章。