thread dump

I like Eric Evan’s book Domain Driven Design very much.  It’s such a nice distillation of a relatively small number of principles, all of which possess real, fundamental value. This is a protein-rich book: it may not feel as filling as the more prescriptive, methodology-driven ‘just-do-as-I-say-and-it-will-come-out-right’ books, but they’re just carbohydrate.  DDD is good for you in the long-term.

I’ve just discovered that you can read some of the book online, via Google Books.  You can also find out more from the DDD Site.

The real point of this post is to share my experience with a small, free tool called wikidPad, which I stumbled on last week when looking for a desktop wiki-based tool to use for capturing Ubiquitous Language (UL) definitions.  Capturing and refining the UL is an essential part of applying DDD, and having a fast, convenient (and open) medium for doing this is essential.  A wiki of some kind is almost ideal.

Most desktop or single-user wikis are either cut-down versions of the equivalent web apps (PHP or whatever), running on localhost ports, or they are single self-editing HTML pages e.g. TiddlyWiki.  Many of these (including TiddlyWiki) are very good indeed, but somehow, none of them has felt quite right for the UL use-case, which is all about getting hyperlinked definitions into a reusable form as quickly as possible.  wikidPad does this superbly well, in my opinion. 

It’s also a small and fast desktop application, which I find a little more convenient than using a wiki app in a browser. Some examples to support that:

1. wikidPad automatically constructs a tree-view of pages on the left hand side of the application – this makes navigation very fast.
2. wikidPad does auto-completion of wiki-words (Ctrl-space), which makes writing new entries which link to existing items very fast.
3. Drag and drop support, and support for multiple tabs – again, all good for speed and usability.

When you’re ready to publish the UL to a wider audience, wikidPad will export the whole thing (or any selected part) as a set of HTML pages.

It’s my first day using this tool, so it may be that I’ll discover something to dent my enthusiasm. But so far, it’s all good.

I’ve long felt that the DSL moniker is a little inappropriate for some (perhaps most) applications of the ideas behind it. The majority of ‘DSLs’ are really just little languages which help solve specific problems in the software development space, e.g. Rake, which provides a very nice language for expressing graphs of dependent tasks.  Martin Fowler has written quite a lot on the subject of DSLs – this paper is a good example of a little language being described as a DSL.

So it was good to hear Jim Weirich (the creator of Rake) make this very point while talking about the DSL hype in this InfoQ interview. The relevant bit is something like 14 minutes in. I like the term Problem Specific Language (PSL), which Jim invents here.

I’m working on applying Ruby to modelling (and reasoning about) a real domain, and driving a tool-chain for forward-engineering artifacts from the Ruby description. Apart from Rake, I’m also looking at RSpec, which uses Ruby syntax to capture descriptions of system behaviour. I’m very keen to work on the ‘real DSL’ problem, looking for the sweet-spot where domain-driven design and programming overlap. This whole area seems very fruitful for Ruby, because the language allows us to create very rich and expressive scripts which not only read quite naturally, but can also control complex processes.