7

Behavior-Driven Development (BDD) can be described as in this blog post as follows:

Behaviour-driven development (BDD) takes the position that you can turn an idea for a requirement into implemented, tested, production-ready code simply and effectively, as long as the requirement is specific enough that everyone knows what’s going on. To do this, we need a way to describe the requirement such that everyone – the business folks, the analyst, the developer and the tester – have a common understanding of the scope of the work. From this, they can agree to a common definition of “done”, and we escape the dual gumption traps of “that’s not what I asked for” or “I forgot to tell you about this other thing”.

So it seems much like a way to manage the requirements of the software and really have a clear notion of what has to be developed and the criteria of whether or not it has been developed correctly.

Domain-Driven Design, on the other hand, is a modeling effort, which puts the focus on the business rules and the construction of a ubiquitous language. Domain-Driven Design furnishes very nice ideas on how to structure the code, how to break a complex domain into smaller parts (with Bounded Contexts), and how to understand different "types" of objects which might be needed in coding, by defining precisely entities, aggregates, and so forth.

It turns out DDD doesn't tell much (as far as I know), if it tells anything, about how to deal with the requirements of the software.

How to bridge the requirements organization and the notion of what has to be developed, to actually developing it, to the point where DDD becomes useful, it seems that DDD doesn't tell.

Since DDD puts focus on constructing one ubiquitous language which employs the business terms and talks about "really understanding what the domain is and needs", it seemed to me at first that BDD and DDD can go along together nicely.

But this is a matter of experience. The only one who has tried can know the results.

My question here is: has anyone tried using both BDD and DDD together? Is it a correct thing to use then together? If not, why they don't go along contrary to intuition?

  • 1
    It turns out DDD doesn't tell much (as far as I know), if it tells anything, about how to deal with the requirements of the software. -- Why do you say that? DDD is a way to model software against business processes using an ubiquitous language (a language that the software engineer and business analyst can both understand and communicate with), so it impacts directly and profoundly on the software requirements. – Robert Harvey May 12 '17 at 1:10
  • 1
    BDD, on the other hand, is the "enlightened" form of TDD. Like DDD, it uses a (more or less) ubiquitous language that the business analyst and software developer can both understand. Its goal is to turn requirements into code. DDD's goal is to turn requirements into software design. The two techniques are not mutually exclusive, nor are they incompatible. – Robert Harvey May 12 '17 at 1:13
  • 1
    I agree @RobertHarvey. My point is that in what I've studied about it up to now, it doesn't seem to suggest a method for gathering and organising these requirements. It encourages the engagements of business people, the creation of the ubiquitous language and so on, so that it sheds light on how to pick a requirement and implement it focusing on the domain. I haven't seem up to now any DDD content actually suggesting a way to gather, organize these requirements so that they are ready to be used in the development process. I thought BDD could furnish this part – user1620696 May 12 '17 at 1:14
  • Neither BDD nor DDD have much to say about the requirements gathering process itself; that process is the subject of entire books. – Robert Harvey May 12 '17 at 2:25
9

Like @robert-harvey already pointed out, the ubiquitous language is ideally the common binding force.

DDD focuses on defining the vocabulary in that language: actors, entities, operations, ... An important part of DDD is also that the ubiquitous language can be clearly seen in the code, too, not only in communication between the implementor and the domain expert. So an extreme view of DDD is quite static: it describes the finished system as a whole.

BDD focuses on defining user stories or scenarios. It is closely related to an incremental process, but it can also be viewed as static: it describes all the interactions between users and the finished system.

DDD and BDD can be applied with no overlapping: BDD user stories can be written using only UI vocabulary (buttons, labels, ...), and DDD can avoid mentioning interactions.

But ideally these two overlap and work together: the BDD stories are rich in the ubiquitous language, describing the user experience with domain concepts. And DDD makes sure the stories can be found in the code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.