Stardate 2011.6: Interesting Exercises

Lately, I've been delving a lot into DDD, or domain-driven design. I find it to be the single most elegant way to tackle really complicated systems. Some people say it's a lot of work, especially just for small apps, but I find it to be completely natural. For example, on a previous job, the users needed a batch publishing system that would loop over a set of Word documents, convert them to HTML, and then save them to a directory which already had publishing features turned on, so that when HTML files were put into it, they'd be served appropriately up to the web. I didn't have time to write more than the bare necessities, but since every class and functional piece of code was named in such a way that the business user understood the meaning of the pieces (for example, I used an IFilingCabinet interface for the documents, which they used all the time of course) and they were able to take it and add to it so that even though they started with the barest essentials, they ended up with something really powerful.

I think it would be interesting for a book on DDD to propose exercises. These could be considered to be a kind of kata for DDD. As such, I'm going to begin publishing exercises that I've thought of, from the very simple kinds of things you might find useful around the house, to complicated, industry-standard systems that are extraordinarily painful and convoluted.

The first kata I propose for DDD is rather childish, but comes from a joke I made in an email the other day.

Name: Mouse Trap Simulation
Description: The idea behind this kata is to write a simple simulation for how a mouse trap should work. There are many variants of mouse traps.

1. The standard spring-loaded bar mouse trap (with cheese)
2. Glue paper
3. Poisonous foods

Let's just consider those three. What are the pieces that make up every mouse trap? How can you write the code so that a mouse trap entrepreneur could come in and extend your system without having to change the original code? What does your test harness look like - does it have a human setting the trap, a random mouse encounter?

One thing to note about it is that the requirements are not well-defined. Feel free to ask questions in the comments!

Goal: The goal of this exercise is to develop a simulated home/work environment where rats may be an issue. The code should be structured in such a way that when a normal person reads it, they can have some idea of how the system works. They shouldn't need to be programmers - for example, they might just be business analysts who dislike rats. The key to this exercise is creating a truly decoupled design that allows every mouse trap to do their own work, without making it difficult for an extender of the system to implement that work. If your base classes/interfaces make it difficult to extend them, then You're Doing It All Wrong ®.

Bonus points: For extra points, design your *test harness* to be extensible as well, because what if a trap can't truly be tested in the same way that other traps can be?