Domain-Driven Design Community

...but the problems are the same.

I was in a phone meeting some time ago with a big Asian company to discuss their problems. They were eight participants, and only one spoke and understood English. So when I said something, the English speaking guy spoke their language and I didn't understand at all. And the same when they discussed things before telling me. The situation and meeting was very tricky and made me nervous and uneasy. Large distances in language, culture and geography... Until they told me about their problems. All of a sudden, the meeting was transformed into well-known territory.

I've spent a good part of my career trying hard to better understand the businesses I'm developing software for, since that helps *a lot* in delivering more value. This is not anything I'm done with. On the contrary, it's something that I find increasingly important. You can't program what you don't understand. Period.

This works both ways. If a business person wants their software development projects to be more successful, it pays off immediately to show an interest in the projects, to get involved with them and learn more about software development and all the changed and rapidly changing rules. For instance, in order to be able to adjust a software project for the better, it helps if you understand what is going on so you know what you'd like to change.

About two years ago I gave a few presentations about how relational databases are facing more and more competition and that several factors indicate that we will be choosing other ways of storing data in the not too distant future.

The term NoSQL was created last year and has morphed into NOSQL lately (Not Only SQL). This trend is rapidly gaining strength. Below I have written down some of the drivers behind the NOSQL movement. Which ones are missing?

• TDD and DDD
For many, this changes the picture completely. The focus moves away from the storage technology.
• Application databases instead of integration database
Then the storage technology that is used is a private concern of the service/application itself and the decision becomes less dramatic.
• Internet scale
The need for scaling out is changing the scene for certain scenarios and eventual consistency is most often good enough.
• We don't need many of the common capabilities for certain applications/services
And we just don't want to pay a high cost for impedance mismatch if we don't get other large benefits.
• Querying and analysis finally moves away from the production databases
Just an example of one reason why we have less of a need for functionality in specific situations.
• Certain types of applications don't fit the relational model very well
A classic example is "bill of materials". Nowadays social networks is an often mentioned example.
• Event sourcing is growing in popularity
This might mean that you only need a persistent log file for that part, a pretty basic need.
• Need for rapid schema evolution
Or very many schemas, or no schemas.

factor10's course "Test First with TDD" (or "TDD på riktigt" in Swedish) is given as an open course for the first time in Malmö in Sweden in April. You can find more information and book a seat here.

Oh, and the DDD course is taking place next time in Stockholm in April.

As I write this, the yearly SAW is under way. One of the subjects I put on the table at last year's workshop was that I thought (and still think) it's about time for a new and *good* "VB".

What do you think? Has it become significantly easier to build software since 1991? Have we as a group become significantly more productive? (If so, would you say "yes" even if we take maintenance into account?)

VB had its merits and its flaws, but I think it represented a big shift in productivity for a big crowd. That said, it's not exactly a new VB I envision. It's something kind of in its spirit, but something that doesn't put lots of obstacles in the way of creating *good* software. It should help in creating software that can be maintained and taken further, maybe by more skilled developers if needed after the first successful application is built and used for some time. Probably also in making it easy to involve business analysts, domain experts, testers...

As I wrote here, there is no lack of new RAD tools ("drag till you drop" etc), but they are not focusing on creating expressive and beautiful code, maintainable software. Is it a law of nature that approachable tools must create bad results below the surface? I don't see that. (Please note that I *don't* expect a tool to make design and software development easy, that's definitely not what I'm talking about. I just don't think it has to add lots of accidental complexity either.)

Why so little (no?) interest from the big vendors? It seems quite easy just to harvest some obvious and proven good ideas and concepts to put together in a nice and approachable package to take a big leap, and I think it would represent a huge difference for loads of non-alpha geeks. Sure, it's a moving target, but this might not be moving at all as fast as some of the current RAD attempts...

I put together my own toolbox as do many others, of course. We would probably do that anyway, but that's not the case for everybody. As I understand it, lots of developers go with the tools they get in the single package from the single vendor of their choice.

OK, there are attempts here and there for what I in the header called a new and *good* "VB". Those attempts are as far as I know from small vendors (and open source of course) and I guess this will spread.

Or maybe the "situation" will have been solved at SAW in a few days?
:-)

It's time for factor10's course "Fast track to Domain-Driven Design (DDD)" again (in Swedish). This time in Malmö in a few weeks.