I felt pretty good about where things were a few weeks ago, but as I started tightening things up and showing the app to others (doing walkthroughs and code talks), I began to feel… well a bit “meh” about it. Something was bugging me about the way it’s come together. Some people refer to this as “smell” – when things work but just don’t seem right. I’m about to change that.
UPDATE: Kevin Dente suggested I might have put my foot in it with my statement below that DDD is simply a collection of patterns. That’s what it means to me, at this point, however that’s not what DDD is. It’s a bit more, obviously, and involves working closely with your client as well as testing the tar out of your code. I’d already done that (arguably) and I should have been more clear.
Enter DDD
Please don’t hang up yet. Hear me out. I knew this day was coming, but I wanted to stay clear of “dogma” and let my instincts and tests dictate the application design. People had mentioned DDD, but to be honest I didn’t know enough about it to impose it’s strictures on the application.
Over the last few weeks I’ve been demoing the app to various people and walking through the code with them and to be honest, the story I’ve been telling is a tad fragmented. I don’t think it’s bad, but there’s a common understanding that’s missing. I’ve tried to pay attention to patterns where applicable, and I’ve also tried to avoid “crufting up” the application with dogmatic adherence to a line of thought.
I think I just got caught in the middle.
Truth be told I sensed this about 3 months ago and at the time I thought “I need to stop and redo something here” – but I wasn’t sure just what it was that I’d redo. So I picked up copies of Nilsson’s and Evans’ DDD books (at the behest of many) and began to read them on the weekends and evenings.
Koolaid or Kool Kid?
I’m sure I’ve just polarized my readership – but I think, perhaps, there’s some common ground here that will 1) help me and 2) help you 
. If you don’t know DDD (and perhaps don’t want to know it because of… well shall we say getting beaten over the head with it), I think watching as I refactor the application with DDD in mind may really help you. There is a lot of goodness there.
If you’re a DDD wonk and have been waiting for me to “come to [Deity]“, well I’m almost there, but not quite. I really like the DDD approach for the way it deals with complexity – but complexity doesn’t exist when the app is small. This is something I’ve struggled to understand with respect to TDD and DDD.
In fact, so does Nilsson as he starts off his demo app, using TDD and DDD. He literally hams his way through his initial unit tests, implementing patterns and principles that will help him, ultimately, deal with an application he knows will get complex. I almost jumped out of my chair saying “how do you KNOW you need the FACTORY PATTERN YET!” and then BAM, he backs his way out of it and out of all DDD implementation until he really needs it (YAGNI baby!). I’m still unclear on this – I know it needs to be introduced at a refactoring point, but at the same time I also trust my instincts to know that all applications will end up being complex if they are successful.
Anyway, I’m now at a point in the life of the app where I can clearly see that it’s complex and needs to be bound by some common patterns and principles. That’s all that DDD really is – a collection of well-known patterns, many of which I’m already using.
A Little Help From My Friends
I’ve asked a few folks I know in the community if they’d be willing to come on and help me out here with implementing some core DDD principles, and also their thoughts on DDD as a whole. I think this will be a very good episode.
I’m never sold on “only one approach” to anything, and I’ll press these guys to help me implement what makes sense. I also know that not everyone is sold on DDD – even some of the more seasoned folks in the community. I was chatting with one of them today and asked what they thought and the answer still has me giggling:
Domain Modeling: Good
Jargon Explosion: Irritating
So very, very true.
I think this will be a really good episode, and to be clear, my goals are:
- Add some elegance using some well known patterns (Factory, Unit of Work, Repository)
- Reduce complexity and duplication (Services that just pass on queries, etc)
- Simplify
I’m aiming for Thursday/Friday for this episode to be ready.
