A couple of views on coupling

Having read both Domain Driven Design and Hibernate in Action recently, I found an interesting contradiction between them...here's what Eric Evans has to say about promiscuous coupling between your domain classes:

"It is important to constrain relationships as much as possible. A bidirectional association means that both objects can be understood only together. When application requirements do not call for traversal in both directions, adding a traversal direction reduces interdependence and simplifies the design. Understanding the domain may reveal a natural directional bias."

...and here's what Gavin King and Christian Bauer have to say on the same subject:

"Good uses for unidirectional one-to-many associations are uncommon in practice, and we don�t
have one in our auction application. You may remember that we started with the
Item and Bid mapping in chapter 3, making it first unidirectional, but we quickly
introduced the other side of the mapping."

So I agree with Eric, but I'm using Hibernate. Things that make you go hmmmm....

Taste-Driven Development

Having used Test-Driven Development for several years now, I am as convinced as I have ever been of its benefits in producing high quality maintainable code. One thing that bothers me, though, is that TDD itself provides no forces to ensure that the small pieces you build are assembled together into the higher-order structures you intended. For example, you can write a clean, concise fully tested set of classes such that your domain model is directly accessing your custom tags for your web app. Of course nobody interested enough in software to read this would ever do such a thing, but the point remains: with the promiscuous coupling encouraged by IDE's that will helpfully import any class from anywhere without requiring you to think whether this violates good taste in the form of layering, abstraction or anything else, we seem to be constantly having to fight against randomly coupled internal workings in good-sized systems.

So I find I'm constantly looking for ways to do what we do at the class level with TDD and do it at the package/component level; that is, allow the good taste desired in the design to be formally expressed and tested with every build. Developers who aren't up to speed yet on the complexities of the system they're working on would be protected from violating its conventions, and the emergent design can be allowed to flourish in a controlled way. On our current project we use a few things to help, such as simian, jdepend, ydoc, lots of checkstyle checks aimed at code quality and the usual test coverage stuff. But a few of us think that what the world really needs is yet another open source java development tool. Oh, no, you say, not another one. Yes, I'm afraid, it's another one. But this one is different - this one uses a business rule engine (drools) to allow you to declare in a text file your idea of good taste and enforce it for your code base. This one even has a user guide. No, seriously. So if design is your bag, have a look at joodi and let me know what you think. It only has a few rules in it at the moment, so it's not overly complicated.

Oh, by the way, if you think the java runtime itself would show good taste, check out what joodi has to say about rt.jar in the sample reports section of the user guide...you might be surprised!

Here's an example rule from the joodi rule file. This one expresses the simple good taste that cyclic package dependence is bad. It's kind of cryptic at first glance, but it basically says that if there exists a namespace (i.e. a java package) that depends on itself (dependence being part of the joodi fact model when your code is analysed), then create a notification including the cause of the problem so that the report provides full traceability for each notification produced. Using joodi is pretty much down to writing rules like this that express what good taste means to you and your project. Welcome to Taste-Driven Development!

<rule name="Cyclic Namespace Dependence Is Bad">
<parameter identifier="namespace">
<java:class>Namespace</java:class>
</parameter>
<java:condition>
namespace.dependsOnNamespace(namespace) != null
</java:condition>
<java:consequence>
drools.assertObject(new CyclicNamespaceUseNotification(namespace.dependsOnNamespace(namespace)));
</java:consequence>
</rule>

Why I Hate Domain-Driven Design

I was feeling pretty good about myself I have to admit. Having just delivered a system that took a year of a dozen developer's lives to complete with the full XP experience working like a treat, on time, on budget, happy customer, etc, etc, I thought I'd finally get my life back and start catching up on all the reading I don't do when it's head down, bum up on a project. High on my list was Domain-Driven Design by Eric Evans, as it had been highly recommended by people I respect a lot. So now I'm depressed. It is such a fine book, no, it's a truly mind-expanding, insightful, gee-now-I-feel-stupid kind of book that I now just want to go back and do the whole damn project again. And this time I'd do it properly. Dammit.

If you'd like to share the joy, as usual my recommendation is to get it on the cheap at Safari

Become what you despise

A lot of agile/TDD/XP folks like me enjoy flouting a very public disdain for "whiteboard architects" and their ilk. These are the ones who haven't written a line of code in ten years or more, serve out voluntary life sentences in financial institutions and impose design decisions from on high while ignoring development teams entirely. They never ask for feedback on their architecture from anyone who sits beneath them on the org chart, as what feedback of value could a lowly code-cutter have? They are far too busy seeking feedback from those _above_ them on the org chart to make sure their career ambitions are on track, and that's a full time job.

So how happy was I when Jon broke his arm and I was pulled off my nice little agile dev lead role and into a six week whiteboard wonderland? Hmmm. In a nutshell, this gig involves designing a technical solution to coordinate half a dozen systems on four different platforms written in four different languages, integrating .NET with J2EE, a rules engine, messaging systems, mainframe yuk galore, blah, blah, snore.  The system will be used by thousands of people every day and carry billions of dollars of business every year  Textbook whitebook architect turf. Oh, and you've got three weeks to get your head around it and come up with a solution and another couple of weeks to write it up and get it approved by the Big Guys Upstairs. No coding for you!  Well, it's been an interesting and enlightening experience - always a good thing. I hope I haven't become what I despise, but perhaps I despise them a little less by understanding them a little more.

Lesson: Same shit, different abstraction

So why is it that we who prefer to spend our time at the implementation coalface smirk at the whiteboard architects? I have noticed during this brief out-of-body experience that one reason is the same as why we smirk at some of our less-than-breathtaking code-cutting colleagues. They can't design to save themselves. Just as many developers solve the wrong problem and can't distinguish between an implementation abstraction and a design abstraction (Dude, don't call it a SQLDataSource if it's role is a DomainStore!), it seems the same mistakes happen at the higher level of abstraction where enterprise architects play. Some of them seem compelled to define the implementations of the solution to the problem instead of just defining the problem, assigning responsibilities to well-nhamed abstractions (SOA, anyone?) and admitting that in the time available they don't have a hope in hell of telling a development team how they should actually build the thing. I can forgive them their transgressions against developers because it's not just them. We do it too. And so do business people. How often have you been given a so called 'requirement' that is not a statement of a problem at all but a statement of a dumbass solution? It has surprised me how well design concepts I'm used to using at the class/interface/component level map to the system/service level.

On this gig I've met one particularly outstanding guy who's an enterprise architect on a parallel project, and I just know he would be a kickass code cutter as well; he must just prefer to get paid properly. So take heart, you too might get lucky and find a whiteboard architect whose pictures deserve to make it off the drawing board!