Martijn ‘s latest entry touches upon a really big issue. For most software developers it’s very hard to grasp the real problem domain of the customer or end user. This has been an issue in requirements engineering and architecture for years already.
When defining a DSM Language, this problem is close to deadly – stuck in the world of solutions, people tend to define their language in that domain. As a result, a lot of detailed properties and relations are defined, and the relation between code and language gets close to 1-on-1.
I’m currently thinking up an example case that I can use to put together a short web tutorial here – or even better, a blog workshop on DSM Language definition similar to the one Dratz is running on abstraction architectures.
Keep an eye out, it will be here soon!