For me software development has become more than just writing code, although ultimately that is what it’s about; a developer writing applications that work and serve a function. As I’ve progressed through my development life, I have picked up techniques and methodologies to help me develop a better application. Some of these techniques are Domain Driven Design (DDD), Behavior Driven Development (BDD), and Test fridge ecosystem Driven Development (TDD). Jeez that’s a lot of D’s! What’s the difference between all of these methodologies and when to use them? Well I’m about to tell you where they fit into my development ecosystem. Again, this is where I’ve found these methodologies to work the best for me.

Domain Driven Design (DDD)

I’ve always thought of DDD as a mindset rather than a code writing methodology. DDD’s main focus is create a dialogue between developers and the domain they are attempting to develop in. For example, if I were writing a blog, then my discussions and inevitably my code would include words like “posts”, “tags”, and “categories”. I’ve always found DDD to be easy for developers to understand. It doesn’t require any tools except for a good whiteboard and some developers willing to talk to each other and their business partners. Below are the necessities that I perceive to properly implement DDD.

DDD Necessities:

  • Whiteboard
  • Open dialogue
  • Domain experts
  • An open mind

Behavior Driven Development (BDD)

I use BDD to express my application’s intent (with code) within my project. The specifications are written using stories and scenarios, and it is my job to make sure that those stories are true through functionality. BDD is cool because intentions are visible, and all your BDD stories are written in English that is understandable to your domain experts. BDD and DDD are tightly interlocked because your stories will most likely come out of your DDD sessions with your domain experts. Below are a overview of the tools needed to implement BDD.

BDD Necessities:

  • BDD Framework (For .Net : MSPEC, StoryQ, SpecUnit.Net, SpecFlow)
  • Story (Test) Runner
  • Discipline of Steel ( the most important thing)

Test Driven Development (TDD)

I still use test driven development, but in a different scope. TDD has turned into my debugging approach of choice when dealing with a client’s code. I attempt to write a unit test to isolate issues. During this process, I can re-factor and learn more about the newly presented code base. Once I can reproduce the bug through a unit test, I can start thinking about what I need to do to solve the issue. This method of debugging only works with code based bugs, and not things like memory leaks.

TDD Necessities:

  • TDD Framework (For .Net : NUnit, xUnit, MbUnit)
  • Test Runner
  • Ability to reverse engineer

Conclusion

As you see above, all these methodologies are alive and well in my development ecosystem and they all play overlapping roles. The thing to keep in mind is that there isn’t a point where I say “I am going to do BDD now!” or “It’s time for some DDD!” These methodologies are applied fluidly but precisely. I cannot stress enough that self discipline is at the foundation of any methodology you use. If you don’t believe enough in the methodology to follow it’s main tenants, then you’ll find yourself undermining your own efforts. At the end of the day, a methodology is a system, a series of steps that you take to develop an application; respecting that system can yield great results.