Wizards of Smart

Dogs and Cats Living Together

You’ve probably read Joel’s post on The Duct Tape Programmer and several responses. I did not like Joel’s post at first, as I thought it far too general and easily taken in the context of “always do it this way.” For the record, I have no problems with the duct tape approach when trying something out, but I’ve been burned when having to work on someone else’s let-me-try-this project that then became a core, production system. That’s a formula for PAIN. That said, I think you can make a case for using a duct tape approach for some, small parts of your application.

This past week I put together a presentation on DDD for my office. I included some slides describing DDDD and CQS as Greg Young has discussed time and again. While I put together those slides and thinking about Bounded Contexts, I had a sudden realization that even within a single Bounded Context or Module, you could mix duct tape with quality when using CQS.

If you look at the diagram above, you can easily see where this is possible. If you split your module into read and write contexts, you can focus your greatest efforts for quality on the write side, where your domain lives, and leave the ever-changing read side to duct tape, RAD, etc. for displaying in the UI or reporting. The idea here is that you will often find that what you need to persist doesn’t change very much, but what you are asked to display changes nearly constantly. That’s at least my experience.

Another benefit to this approach is on the sales pipeline. Creating applications consists of these two parts: reading and writing. You may find that clients who have their own internal developers may not want to hire a consultant or contracting firm to build an entire app at their normal rates, but if you can provide them the write side and architecture guidance for the rest of the app, you may be able to sell more projects and keep your people happy working on quality code and quality projects. Of course, that’s just theory at this point.

So is this a case of “mass hysteria”? I don’t know. I like the idea, if not so much for the inclusion of duct tape as the possibility of limiting changes to the core domain models in an application architecture. I’m curious to know what others think or have done.

If you have been following the DDD and DDDD waves, you’re sure to have come across the CQS pattern. When I first heard of this, I immediately liked it but thought it was surely a pattern for very, very large systems. Most systems probably don’t need CQS, but this morning over breakfast, a discussion with my wife on child learning patterns made me rethink this.

We have a friend whose children have grown at very different rates of reading comprehension and writing skill. The interesting part is that the rates are nearly opposite from one another. The one with excellent reading comprehension does not excel at writing while the other is and excellent writer but has trouble reading. I found this somewhat strange. After all, logically, I would think that the one who reads should be able to write better. But that’s not the case. No one can do everything best. The same is true of databases.

This is such a true statement that in the Collective Intelligence session at the Houston ALT.NET Open Spaces, four distinct database tiers were promoted for proper separation of concerns to allow each tier to most effectively perform its task. Is this necessary for every application? Probably not, but as we move toward a more virtualized server world, the cost is really swinging in the favor of using multiple databases for reading and writing concerns. This may break the YAGNI principle, but I think we may often find that simplest may really be the best, simplest, smallest part that can fit the bill. (I’m sure that last statement will really ruffle feathers, but that’s where I am atm.)