DD vs. DD – The End

I had an old post, back in July 2008, where I had a few comments on Data Driven vs. Domain Driven applications. It will be almost a year soon since that post, and I have definitely learned a lot since then. One thing I learned for sure, is to pick your the battles. You cannot fight a developer who knows data driven applications since day one and nothing else, that domain driven applications are not necessarily more ‘efficient’, but more maintainable, allow better link between domain concept and software, allow change, pass the reality tests when change in business is coming. It’s the same as trying to convince someone who spent 2/3 of his career without testing and sees no value in it, suddenly to start TDD or even ‘worse’, BDD. Why to bother? I know my stuff well, don’t I? Look, XX years in the industry are not wasted. No, they are invested with a little ROI. But these are religious wars. Useless. Therefore I am off the topic, and just learning, exploring, and implementing things I see the right way at the given moment. Once you concentrate on doing that rather than chasing ghosts to convince, you realize what is right and what is wrong, without a need in side-kicks.

So this is the end of discussion for me. Why did I post this? Well, it was funny to get today a comment, referencing the post. I forgot it long time ago, but someone is still fighting the fight he will eventually lose…

4 Comments

  • Simple is not necessarily stupid. KISS, keep it simple and stupid, please.

  • @Jiang,

    1. I am not going to play the silly game you are dragging me into.

    2. I will block your comments from now on if you can't leave a debate that none wants to keep (you just don't get it, don't you?).

    3. I would definitely recommend you to re-read the software principles, as you are not remembering them properly (KISS always stood for "Keep it simple, stupid" - en.wikipedia.org/.../KISS_principle) - but no worries, it might be just English understanding/interpretation.

    PS: and also when you leave you blog spot, leave a correct address. 10x

  • Sean, first of all, please don't block anybody's comments.

    domain-driven is abstraction and it leaks because we don't deliver our clients domain model but complete application and it includes database and user interface too. for small projects I wouldn't even bother with anything but simple scripts that would contain all of it: sql/business logic/UI without any separation whatsoever.

    as codebase grows, you might want to upgrade to active record pattern and eventually perhaps to DDD.

    I know DDD makes sense, so does flying bird. if we humans wouldn't do the simplest thing that can possibly work for given context, today's planes would have flapping wings.

    building proper domain model for every single application out there would be massive waste of resources for little extra value. not worth.

  • @lubos,
    I was not blocking anyone's comments, unless they are extremely offending (this is my blog after all). There was a setting not to allow comments for posts older than 3 months, now it's removed.

    In regards to domain, it is way cheaper to build application with domain (when there's a need), then to start without and introduce later. Business apps have domain. Fluent NHibernate is a tool that allows you to do that with such an ease that it's amazes me each time I am touching it.

    Either way, we all intelligent people, and clients will determine what way to go. When my clients see the difference between data driven business application and domain-driven business application, they already know the difference. And that makes me happy.

Comments have been disabled for this content.