We Are Not Doing Domain-Driven Design

Recently (13 years ago now!) I joined a new project, and within reason, and excluding some legacy systems we have to talk to, we have the “luxury” of an almost greenfield project. Probably as greenfield as you realistically get anyway.

I was brought in partially as a good old fashioned coder (the project needed another person cutting code) and partly as guys in the team knew my blog and general approach to software development and wanted to inject some of those ideas into the team. I’m not sure exactly what they were expecting, and I’m not sure if they got what they were expecting, but suffice to say the first two weeks has been turbulent and frenzied.

I’m certainly not known for my subtlety, nor for my coding skills which are by no means the best you can buy in. What I feel is my key strength is my ability to look at the wider picture than sometimes teams have the luxury to do, and to push some of my enthusiasm and energy into a project. I’m sure I’ll blog in the near future about the actual impact my presence has had on the team and the project, but this blog is primarily about why we are not going to be doing DDD.

But Jak Does Domain-Driven Design

One of the factors that made the client hire me was my knowledge around DDD, or at least my projection of that knowledge on the web. It was certainly something they felt could have helped some of their past and ongoing projects, and something they thought would be a real help to them. I don’t think anyone suspected I would come in and say “Hey guys, lets all do full on DDD”, so luckily for them I didn’t, what may have surprised them is that I did pretty much the opposite. In fact my early assessment was this project really didn’t have any need for most of the stuff in DDD — fundamentally it, like the other projects in progress by the same team, was a CRUD application at heart. Data out of the DB, a bit of manipulation, some input by users and services, and dump the data back to the DB.

Many out there disagree with my general statement that CRUD applications don’t make good candidates for DDD — but not only do I stand by that statement, but two of the other client’s projects nearing completion showed some of the real pitfalls of DDD. While previous projects had attempted to use parts of DDD…