Featured in AI, ML & Data Engineering

In this article, author shows how to use big data query and processing language U-SQL on Azure Data Lake Analytics platform. U-SQL combines the concepts and constructs both of SQL and C#. It combines the simplicity and declarative nature of SQL with the programmatic power of C# including rich types and expressions.

Featured in Culture & Methods

The book Agile Leadership in Practice - Applying Management 3.0 by Dominik Maximini is an experience report of the agile transformation journey of NovaTec. Maximini shares his experiences from applying principles and practices from Management 3.0, success stories, failure stories, and learnings from experiments.

Featured in DevOps

Yuri Shkuro presents a methodology that uses data mining to learn the typical behavior of the system from massive amounts of distributed traces, compares it with pathological behavior during outages, and uses complexity reduction and intuitive visualizations to guide the user towards actionable insights about the root cause of the outages.

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.

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.