Behavior-first design is an enterprise software development pattern to simplify implementing user stories in an agile environment, as well as modeling organizational and customer behaviors in general.

In software engineering, Behavior-driven development (BDD) introduced an advancement to Test-driven development (TDD) by decoupling unit testing from implementation and making tests more agile.

At the same time, Domain-driven design (DDD) narrowed the gap between the business domain and the technologies used in implementation. However, DDD does not provide a solid, traceable link between user stories in an agile environment and their direct execution as business logic, nor does it easily capture organizational and customer behaviors.

This gap is what behavior-first design addresses.

The purpose of behavior-first design is to translate a user story into an implementation seamlessly. Testing a business behavior unit is inherently meaningful to the business domain and therefore more agile, aligning with the intent of BDD.

The simplicity of behavior-first implementation becomes evident when using a framework designed for it — for example, Behaviours.js.

• Role: A middleware that handles authorization and represents multiple behaviors.
• Behavior: An object that represents a piece of logic behind a user story in an agile environment. All behaviors expose the same interface to obtain inputs and deliver outputs. A behavior can be self-executed or executed by a controller and knows which repository it operates on.
• Goal: An object or collection delivered from a behavior that can be directly bound to a user interface or sent through a web service.
• Operation: An enumeration that defines the lifecycle of all behaviors. A behavior selects some or all lifecycle operations.
• Extension: Middleware that can be provided to a behavior to execute before or after a lifecycle operation.
• Dependency: A behavior can use another behavior. When it does, it suspends execution at its current lifecycle operation until the dependent behavior completes.
• Controller: An object that executes behaviors and maintains the dependency chain.
• Failure Condition: A condition provided to the controller to indicate whether a behavior succeeded or failed, enabling proper dependency management.
• Cancel Object: An object returned when a controller starts executing a behavior, allowing later cancellation.

• Domain-driven design (DDD): Behavior-first can be implemented as a layer on top of DDD but does not depend on it.
• Command pattern: Shares conceptual similarities but behavior-first projects user stories more explicitly into implementation and testing.
• Middleware: Used to inject cross-cutting functionality into behaviors.
• Workflow patterns: Used in a simplified way to enable the controller to manage dependencies.
• Naked objects: Shares encapsulation of business logic but differs in not auto-generating UI and supporting web services directly.
• Model–View–Controller (MVC): Compliant with MVC, serving as a refined model layer. Enhances MVC testability by guaranteeing that the goal reflects the view state.
• Model–View–ViewModel (MVVM): Similar to ViewModel goals but does not couple binders to the view layer, keeping the view independently testable.
• Flux (ReactJS): Similarities exist between Flux actions/stores and behaviors, and between Flux dispatchers and controllers. However, unlike Flux, behaviors and controllers are not view-coupled.
• Clean Architecture (Flutter): Comparable to Flutter use cases, where each use case encapsulates a single business action in the frontend as a rich/fat client. However, behaviors differ by being headless, enabling them to run independently of the presentation layer and adapt to broader organizational or customer contexts.