Glossary¶

Definitions of key terms and concepts used throughout the BDD Framework Design documentation.

Core Components¶

BDD Step Layer : The outermost layer that maps human-readable Gherkin statements to orchestrator or service calls. Contains no business logic or implementation details.

Command : A declarative object that describes what action to execute, including the action type and associated parameters. Commands are serializable and auditable.

Domain Models : Simple data structures representing workflows, requests, statuses, and results. These remain generic and technology-neutral.

CLIResponse : A generic envelope that carries raw output from executors. Can contain JSON, text, logs, or mixed formats.

WorkflowResponse : A typed domain-level result model representing the outcome of a workflow. Can be hydrated directly from structured output or produced through a lightweight parser.

Executor : An abstraction layer responsible for how commands are executed. May represent local subprocess execution, remote execution, or queued mechanisms.

Orchestrator : High-level controller that manages workflow lifecycles, including submission, polling for completion, and result collection.

ParserFactory : Optional component responsible for transforming raw executor output into structured response objects. Used only when output requires normalization; structured formats (e.g. JSON) can hydrate models directly.

Service Layer : Coordinates domain logic by building commands, passing them to executors, and processing responses (directly or through optional parsers). Maintains stateless composition patterns.

Architectural Concepts¶

Declarative Commands : Commands that specify what should happen rather than how it should be implemented. This approach enables traceability, replay capabilities, and audit trails.

Lifecycle Management : The process of managing long-running workflows through distinct phases: submission, monitoring, and finalization.

Polling Pattern : A workflow management approach where the orchestrator periodically checks the status of submitted workflows until completion.

Separation of Concerns : Architectural principle ensuring each layer has a single, well-defined responsibility without overlapping concerns.

Implementation Patterns¶

Command → Executor → (Optional) Parser → Response : The standard flow for processing requests: declarative command → execution → raw output → structured response.

Extensibility Points : Specific locations in the architecture where new functionality can be added without modifying existing components (e.g., new executor types, parser strategies).

Plug-and-Play Executors : The ability to swap different execution implementations (local, remote, queued) without changing service or orchestrator logic.

Stateless Services : Services that don't maintain internal state between operations, enabling better scalability and testability.

Testing Concepts¶

BDD (Behavior-Driven Development) : A software development approach that focuses on the behavior of an application for business stakeholders, using natural language constructs.

Gherkin : A domain-specific language for describing software behaviors in a natural language format using Given-When-Then syntax.

Workflow-Centric Testing : Testing approach focused on end-to-end workflows rather than individual component testing.

Quality Attributes¶

Auditability : The ability to track and review all actions taken by the system, typically through command logging and structured responses.

Extensibility : The ease with which new functionality can be added to the system without modifying existing code.

Maintainability : The ease with which the system can be modified to correct faults, improve performance, or adapt to changes.

Traceability : The ability to track requirements, implementation, and testing artifacts throughout the development lifecycle.

Safety and Scope¶

Architecture-Focused : Emphasis on structural patterns and component relationships rather than specific implementation details.

Conceptual Examples : Illustrative code snippets that demonstrate patterns without providing production-ready implementations.

Generic Implementation : Approaches that remain vendor-neutral and don't reference specific technologies, platforms, or proprietary systems.

Vendor-Neutral : Design approaches that don't depend on or reference specific commercial products, cloud providers, or proprietary technologies.

All terms in this glossary refer to conceptual patterns and architectural components. No specific technologies, vendors, or proprietary implementations are referenced.