Domain Driven Design...revisiting good ol' fashion OO.

A few weeks ago I attended the Gateway Software Symposium put on by the guys from No Fluff Just Stuff. While I was there, I got the opportunity to listen to Venkat Subramaniam talk about domain driven design. I almost skipped out on it for something else, but Venkat's knack for speaking is always good for an enjoyable lecture at the very least...so I went for it. As expected, Venkat gave a great talk. While the content convinced me even further that DDD is essentially a repackaging of old ideas, it also made me realize that some of the things that have bothered me about some of the ways we utilize patterns, and how many of them are even enforced as standards. This is just evil. Some of this stuff is so ubiquitous that we just accept it as perfectly normal. How many of you have worked on a project that looks something like the one below (hopefully with a few more classes)?

I know that I have...and not just one. Now, mind you, this project is trying really hard to have good practices. It wants to reduce tight coupling...heck, it might use DI a la Spring or Google Guice. What it does more than anything is insult our intelligence. When I see a project like this, it makes me wonder why all this poor User has been scattered all over creation. I feel like this project is trying to be a self-describing code cookbook. It practically begs you to right a BO, a controller, a DAO, a model object and a factory for every class you create. Now, I know we all hear a lot of people telling us not to put business logic in with our model. I say, "Bullocks!"...put logic where it belongs, wherever that may be. Sometimes our objects want to know how to do things for themselves. Not only that, but why are we all so afraid of maintaining state in our applications? Yeah, it comes with some complications...but sometimes those complications are worth it and even appropriate.

I want us to start taking a hard look at what the users are saying about how they work. Listen to what they are doing...how they are working now. You probably had a professor use the old analogy of the bicycle and how all bicycles have a few attributes and actions that are common to them. That same professor probably talked about 10-speeds and how they have some extra attributes and actions that a plain old bicycle might not. I often wonder what this professor would think of seeing:

int gear = bicycleBO.getCurrentGear(tenSpeed);

bicycleBO.setGear(tenSpeed, gear+1);

I will tell you exactly what he would say:

tenSpeed.upShift();

I am not advocating that we go back to the days of gigantic all encompassing classes...where a bicycle knows how to do anything that one might possibly want to do with it. I mean, I might want to hang my bicycle from a tree, but that does not mean that my bicycle should know how to climb trees. I am merely saying that we need to stop worrying so much about applying patterns across the entire landscape of a project and start thinking about the design that fits best.

technorati tags:domain, driven, design, java, patterns, misuse