Behavior first design
Behavior-first design is an enterprise software development pattern created by QuaNode team to simplify implementing user stories in an agile environment or organizational and customer behaviors in general.
In software engineering, Behavior-driven development - BDD - introduced an advancement to test-driven development in which it decouples unit testing from implementation and makes writing unit tests more agile. But although the domain-driven design is breaking the gap between the business domain and the technologies used in the implementation, it lacks a solid link to user stories in an agile environment or to the organizational and customer behaviors in general. This is the problem that behavior-first design came to solve. The purpose of behavior-first design is to translate a user story into an implementation seamlessly. Besides that, testing a business behavior unit is so meaningful to the business space so more agile as aimed at behavior-driven development. The simplicity of implementation using behavior-first design shows up when using a software framework that implements it check here.
Role: A middleware that handles authorization and represents multiple behaviors.
Behavior: An object that represents a piece of the logic behind a user story in an agile environment. All behaviors have the same interface through which behavior can obtain inputs and deliver outputs. A behavior can be self-executed or executed by a controller. The behavior knows which repository it operates on.
Goal: An object or a collection that is delivered from a behavior and can be directly bound to a user interface or sent to a client through a web service.
Operation: An enumeration that defines the life cycle of all behaviors. A behavior selects all or some of the life cycle operations.
Extension: A middleware that can be provided to a behavior to be executed before or after a life cycle operation.
Dependency: A behavior can use another behavior. When a behavior uses one or more other behaviors, it is suspended at its current lifecycle operation until receiving the output of the last behavior in the dependency chain.
Controller: An object that executes behaviors and maintains the dependency chain of each behavior.
Failure Condition: A condition provided to the controller when the output of a behavior is being delivered to indicate the behavior's failure or success so the controller can manage the dependency chain.
Cancel Object: An object obtained once a controller starts executing a behavior to have the ability to cancel it later.
Domain-driven design: Behavior-first design can be implemented as a layer on top of an implementation of domain-driven design but is not dependent on it.
Command pattern: Behavior-first design inherits some ideas from the command pattern but is different in the solid projection of the user stories in an agile environment and tries to simplify the other side of behavior-driven development.
Middleware: Middleware is a concept that can be implemented on different levels of software. The behavior-first design uses it in a simple way to inject cross-functionality into behaviors.
Workflow patterns: Behavior-first design uses the workflow patterns in a simple way to enable the controller to manage the dependency chain.
Naked objects: Behavior-first design inherits the idea of encapsulating the business logic onto the business objects from the naked objects pattern but it is different in two things it does not force the user interface to be automatically created from a goal and the other thing is that the intent of the behavior-first design as a pattern is not only for the logic behind a user interface but also for web services.
Model view controller: Behavior-first design is compliant with the MVC pattern and it can be implemented behind MVC as a model layer. Behavior-first design is considered an enhancement to MVC because it is hard to test the controller unit without the view unit in MVC considering that testing only a model unit is not enough because it is commonly not reflecting the view state but behavior-first design guarantees that the goal is reflecting the view state so in most cases it is enough to test a model unit which implements the behavior-first design.
Model View ViewModel: Behavior-first design inherits the idea of reflecting the view state using a ViewModel like a goal delivered from behavior but the behavior-first design is different in not forcing that the binder belongs to the view layer as in the XAML case which makes the view is not separately testable. In a behavior-first design with MVC, the controller owns the binder and the view is separately testable.
Flux pattern (ReactJS): Behavior-first design and Flux pattern have similarities where actions and stores in Flux like behaviors in Behavior-first design and dispatchers like the controller but the difference is that behaviors and controller in Behavior-first design are not coupled with a view like Flux.