I am building a DDD system and we have all the requirements on paper for the system already set. There is a disagreement on how we go about building our domain model that I need an opinion on.
My preference is to take the requirements and sketch out a basic domain model with the outline for the classes, their properties and behaviors and relationships on a whiteboard or visio. I then take that and start building unit tests that I use to build and test my model out piece by piece.
My coworkers seem to think this is not good TDD+DDD practice. They think you should not sketch out anything and starting building test, and design your model as you go through the “feel” of the tests.
Which one is considered “Proper” TDD technique when building a DDD model?
Like any kind of software engineering question, the answer is often “a bit of both”.
You can’t really write any tests unless you have some idea of what it is you’re going to be testing, but you can also use your tests to influence your model design. Maybe this all happens inside your brain, or maybe you document the process, but (in my opinion) you’re going to have to use both ideas in the end.
Personally, I would do a couple of use cases, take a stab at the domain model, then write tests for it and see what design problems the tests throw up. Rinse and repeat. This should all be done in collaboration with the rest of the team.