Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Behaviour-Driven Development Combined with Domain-Driven Design

Behaviour-Driven Development Combined with Domain-Driven Design

Behaviour-Driven Development (BDD) is very much about conversation and examples but there is another part of BDD, the software design part, Konstantin Kudryashov explains when looking into how BDD can be used with Domain-Driven Design (DDD) by combining the conversional bits with a domain-focused design activity.

Kudryashov, working as a BDD practice manager, describes two styles of writing scenarios for a user story as used in BDD; an imperative style describing how the application will work from a technical perspective, often coupled to the implementation, and a declarative style, which he prefers, describing the problem and what the user wants to achieve. Whatever style used most BDD practitioners will stop at this level and use these scenarios to drive the implementation, but Kudryashov believes this is not enough, there are a lot of details missing that are important to the business. By talking with domain experts clarifying naming, finding missing relations and so on, scenarios can be written with more details and when written in a common language shared by business people and developers, a ubiquitous language will emerge, a key concept in DDD. By writing scenarios this way, Kudryashov claims that the scenarios can become a domain model.

Pushing for ubiquitous language hard enough makes your examples a domain model.

BDD and DDD ways of testing The approach for most BDD practitioners is to test outside–in by testing every scenario through the user interface, UI. In contrast, what DDD practitioners care most about is the domain core which for them is hidden behind a slow and fragile UI and they therefore tend to work middle–out, starting with the domain core and not until the implementation of the core is stable enough, an implementation of a UI on top of the core is done.
Emphasizing this, Kudryashov quotes Vaughn Vernon from his book Implementing Domain-Driven Design:

The application boundary, or inner hexagon, is also the use case (or user story) boundary. In other words, we should create use cases based on application functional requirements, not on the number of diverse clients or output mechanisms.

In order to bring BDD and DDD practices together the two techniques needs to be combined and Kudryashov does this by first removing the UI then running tests through the domain. Starting with the domain the conversation with business people becomes the architect; depending on the words used to describe the problem domain a different architecture emerge, natural to the domain. One advantage Kudryashov has found working this way, removing the need for persistence and a UI before working scenarios can be shown, is a significantly shorter feedback loop in the conversation with domain experts, improving the understanding of the domain much faster.

With this approach the UI stops being the centre of an application instead becoming just a controller for the domain. When the UI is added only scenarios critical to the UI and the application are needed since the domain has already been proven to work.

In a presentation last year Ian Cooper talked about testing of behaviour when using the Hexagonal Architecture.

Rate this Article