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.
[CQS]: Command Query Separation
[DDDD]: Distributed Domain Driven Design
*[DDD]: Domain Driven Design