Understanding the Business

We now arrive at the space between designing our application and planning how that will happen. Leaping over this gap right into planning might mean we lose some of the hard work that a lot of people helped put together. We need something that bridges this divide that can capture the knowledge that has been shared with us and can be used to test us to keep us honest. For this, we turn to executable specifications and behavior-driven development.

Behavior-driven development (BDD)

Behavior-driven development (BDD) is a form of living documentation that, in most cases, can be formatted in a way that makes it machine-readable, so it can be used as part of a continuous integration and continuous delivery (CI/CD) pipeline to perform acceptance testing—all while still being completely readable by non-developers. The purpose of the documents that we create using BDD is to keep the distance between what the business needs are and what is developed to implement that need as small as possible. Domain experts and developers will share and collaborate on the documents.

If we are already using EventStorming or some other DDD tool to develop the ubiquitous languages and the bounded contexts, we will be able to ease into BDD. We will take the capabilities of each bounded context, break those down into features, and then provide example scenarios for each feature.

The scenarios should be written in such a way that they describe what we want the application to do and not how we want it to be done. For example, if we were writing scenarios for an authentication module, the following would be a poor example of a scenario: