Domain Driven Design with BDD

BDD or Behavior Driven Development is an approach to software development that encourages driving software development from a strong focus on the behaviour of the system as perceived by its users. When we do this it helps us to build bridges between the problems that we solve and how we solve them. This is closely related to the design approach of DDD and supports and reinforces it.

The modern approach to BDD using tools like Cucumber and SpecFlow is really a form of "Acceptance Test Driven Development" (ATDD), but now we are really getting into the jargon.

In this episode, Dave Farley explores how we can use this behavioural focus as a tool to better structure our software development and software engineering approach. How it can enhance our understanding, bridge gaps between different groups of people in the development process, better structure our development activities to focus more on the outcomes that we are aiming for and make the whole thing more testable.

-------------------------------------------------------------------------------------

🎓 CD TRAINING COURSES 🎓

📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses.

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
(Paperback version available soon)
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble

(Please Note some of these are 'Affiliate Links' meaning that we will make a small amount of money if you buy one of these books, without it costing any more to you.)

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[mirdanaazartash]

"this is a free 15-minute video what do you expect" Lol, now I appreciate it more, thx for the video

[kingscrusher]

I would just like to say that myself and my brother really appreciate your insightful videos. They seem to be a very clear cut crystalisation of many of the GOTO conference videos we have avidly watched over the last few months. I have been at times been quite cynical of TDD in certain forms but in one of your other videos (BDD vs TDD) as well as this one, I can see that BDD is really an effective and potent customer-relevant tool. In your BDD vs TDD video in particular I like your applied checklist for things like separation of concerned, etc - and basically everything one thinks makes good internal quality of software. That as a checklist for BDD for me makes the whole concept much more effective and very lucrative. We both liked your amoeba illustrations there mapping tests to code and how you can just be doing tests tokenly if the BDD tests not created first. As a small business owner, I am more keen on the BDD interpretation than the more technical TDD. In fact, I am thinking of having some days to dream up my own BDD requirements to try and improve current facilities. Thank you for sharing your great insights. Cheers, Tryfon

[Oswee]

I'm a simple man. I see new CD video, i click Like. :) Thank you for sharing your knowledge. :) One thing i am thinking about is... to model systems the way that they are always easy to transform. Rename things, move around etc. Like.. "The Change" should be first class citizen. You never will be able to establish ubiquitous language upfront. You never will find The Domain Expert who will tell how to name and group domains, etc. So... you should be able to go with whatever works today, but be deeply comfortable to change that thing whenever a better idea will came into your mind. I could trace that even back to monorepo/polyrepo battle/setup, build systems, issue tracking, feature toggles, etc. The infrastructure should be in place to be comfortable with refactoring. If you are not comfortable with refactoring, this will lead to really bad products.

[marna_li]

In my career it always seems like there is too little focus on the product and understanding its use cases. Developers just start to write code without proper analysis and design.The focus then is on structure and how to map what is in "User Stories" - since there are no clear mapping between code and Use Case. Understanding the product and code is largely two different things. And yes programmers like to tackle problems from a technical perspective, that is what most focus should be if you ask them and not meetings. But I argue it is rather about understanding the domain.

[bleki_one]

With an ubiquitous language we also solve the problem of using the same term for 2 different things. The current example from my experience was "a partition" which was used in terms of the group of rows in database and the Spark dataset partitioning. So when someone said a partition ID I was confused what are we talking about.

Also for me learning a domain language, when joining a new ptoject is one of priorities. I'm always looking for joining beginner courses or trainings at the start of a new project. Like the "Payments 101" course when worked for a payment processor, or the junior energy analitics training when worked on a energy bills validation system.

In my projects BDD meets the DDD at the domain service layer.
BDD creates the interface and DDD creates the implementation.

[PereViader]

Thank you so much for the content you create. It's helped me and our team take a different mindset. We are still not there but moving slowly there.
It's quite hard advocating for this on the gamedev industry.

[washedtoohot]

I would like to see a video where you walk us through creating executable BDD specifications. There are some examples in this video of them, but how did you arrive there? How to go from mere specifications to executable specifications? Any tips? Steps involved? Thought process?

[BrunoGabrielAraujoLebtag]

Mind-blown, life change video. Thank you so much!!!! Separation of concern from concept to implementation wow... Mind-blown

[chunheguo]

Hi Dave, thx for sharing your knowledge. A question regarding BDD, you described a case when it is well imiplemented, but what if it isn't well implemented, what are the pro/con to trying to refactor/reimplement BDD the correct way?

[urzytkownikYT]

Hello Dave, thanks for your content, little offtop question:

When using TDD do you always refer to unit or integration testing?
Or could there be just integration tests?

I want to apply TDD to game development but since in gamedev continouous change of design and refactors happen I also have to rewrite my unit tests, thats headache.
But integration tests used to artificially pass through the whole game without unit testing each single system seem less prone to refactors forced by changing design.

Thats not right video to post the question under but I need this help :)

[johnpritchard]

Great video, but how would you define the HOW in this process?
If the Delivery team work to define these BDD style Stories\scenarios that are independent of the solution, when\how is the actual Solution then defined? And how are the details for the solution captured?

[pianochess]

If my system consists of separate ui and Server api (e.g. Java rest-api and react Single page application) how would these tests look? Would they be end-to-end (selenium) or would I Test the two parts separately?

[androkles]

Thank you for the video - I appreciate the simple and concise examples, and I am a huge advocate for DDD. But I do have a question regarding your examples. How is the acceptance test evaluated here? There does not seem to be any assertions in the specification's test class. Is this simply an oversight in the example?

[ChrisAthanas]

@14:05 the id and string arguments are swapped making the slide a bit confusing

[juandupreez]

I love these BDD videos. Although I would like a lot more practical ones. Most BDD examples cover basic test cases to get you started but what about the more complex system?

Like how would one define features for automated jobs and not user interactions? Would the 'when' be 'when I run the job' or is that too specific?

Also how do teardowns work? I find it fun to test changes in system states, but difficult to revert to an original state after each test.

Okay one last question. Should steps be independent or can there be a context that changes as steps continue? For example, I would rather write:

Given there is an employee
And this employee has age 29

Than

Given employee '132' exists for year '2021'
And employee '132' for year '2021' has age '29'

I feel some more detailed BDD practical example videos would help a lot.

[gronkymug]

Dave, I could not find any videos of yours where you talk about hexagonal or clean architecture specifically. It is obvious that BDD is awfully similar to clean architecture as it has use cases as one of its layers, but I wonder if you could talk about these architectures and compare them to each other a bit. Maybe Hexagonal, Onion, Clean and Microservices discussion to see how all this nicely connects with BDD and DDD.

[queenstownswords]

Hello Sir. I am implementing a structure with the following hierarchy: Product, Functional Area, Scenarios. A product is a ship-able piece of software (such as a mobile app or web service). A functional area is a child to the product that maps to what you call a 'problem domain'. A scenario is a child of a functional area. A scenario can be tested via 'given-when-then' (gherkin) or via 'describe-it' (jest). In either case, the 'domain language' is agreed by the 3 amigos and must remain constant between the story, test, release notes, and support documentation. Does this approach match what you are discussing here or is there a difference between DDD and my current approach? If there is a difference, can we discuss via video or some zoom conference? Thanks

[krumbergify]

We used a Gherkin framework in a previous assignment and frankly I hated it. The test framework performed regex matching on our gherkin cases in order to invoke the right code, but it was really hard to execute linters on our tests because the english prose was not translated to python until runtime.

It was also not possible to apply RAII like you can do easily with pure Python.

I found a bug where one test did

Start service X

and other

Start Y

they were supposed to match different rules but due to a misstake in the regex they ran the same command.

In short - I want to see real code in my tests, otherwise the distance from idea to implementation is too large.

[DodaGarcia]

Bear B'n'B 😂😭 I love the little touches