• (nodebb)

    Depending on your opinion about brace style, even those could be wrong.

    Addendum 2026-06-09 10:18: P.S. I can't believe I'm frist so late in the morning.

  • (nodebb)

    DDD sucks because one of it's core principles of only using business terms for your types and members is void of any connection to reality.

    Simple example: I once worked for a client where the term "location" has six different meanings. They were so self aware that they invented a seventh, which obviously had an overlap with most but none completely. So nobody actually used it. And before you ask, the term ranged from a simple "address" to a "telephone number" to "a person that was assigned to a region with a specific customer base".

    TL;DR: The worst thing you can ever do is try to incorporate business terms in your code, ever, especially when they aren't even in the same language as the programming language and DDD basically demands it from you, so it sucks. Cause pretty much every other idea is basically a more dogmatic approach of patterns and principle that long existed before on their own.

  • 516052 (unregistered)

    Yea, DDD is fine as a way of designing your specification. And it's fine for designing the user facing part of your system so that things on the UI are named corresponding to what they represent in the user space. But don't let it creep into your code. Just don't.

  • (nodebb)

    Excluding the curly-brackets, every line in this short snippet is wrong, which is impressive

    Even the first line seems wrong, because why does the overall namespace name-path contain the word "Documents" ?

  • (nodebb) in reply to 516052

    But don't let it creep into your code

    In general, you can't avoid it unless you name variables or functions or classes in reference to "BusinessThingy27".

  • (nodebb) in reply to MaxiTB

    I once worked for a client where the term "location" has six different meanings.

    That's not really a DDD problem, but a business terminology problem, and it would have an adverse effect on any development process, whether it goes to the extremes of DDD or not. Well, unless it talks about BusinessThingy27, in which case you have a different, and far worse, problem.

  • Officer Johnny Holzkopf (unregistered) in reply to MaxiTB

    That's actually important to remember. Sometimes, you end up with a hodgepodge of English and "foreign" words, forming identifiers and creeping into source comments and repository messages, and it might get worse when you have to cooperate with tht well-known "cheap" developers from different countries, add some misspelling, and then you involve AI, and it only gets worse.

    string setAtributeKundenrechnung(string theAccountNombre, string elObscuroLieferanschrift, string Obj5574id2, double cenaEUR)

    Additionally, things in the actual business can change, so the domain-specific terminoloy that was formerly right is now wrong, but the wrong words still live on in the source code where they now don't make any sense, are misleading, or simply don't apply anymore.

    double calculateBSHGErstattung(int paragrav, double hasPaid, double price_in_DM, string SKUs)

    Yes, there's everything wrong with the examples. Everything.

  • tatoun (unregistered)

    I once worked for a client where the term "location" has six different meaning

    well that's exactly where ddd should help you in domain terms that's 6 different things and should have 6 different names

  • Development-Driven Development (unregistered)

    That's where you just wing it

  • 516052 (unregistered) in reply to Steve_The_Cynic

    Yea, I was too terse. Sorry about that. It brought back memories in me.

    What I meant was that you should have a firm grasp of when and how you implement business logic in your code. And that while in some situations it makes sense to follow the names and processes you are automating closely that is NOT always the case.

    Basically, what you want to do when automating a process is not to mirror match the process it self, down to the names and steps but to create a process that is familiar enough to the end user for an easy transition but still leverages the inherent advantages of being automated.

    And I've worked in and seen far too many situations where this was not done properly.

  • airdrik (unregistered)

    reading the url for the article had me thinking about what "TheDailyWTF-Articles-Driven-Development" might entail. On the one hand, it could be about distilling the wisdom of ages from the articles published on this site. On the other hand, it could also be about "don't do anything which someone might later want to post on this site". In either case I could still see something come out of that that would end up here.

    Related: a former coworker coined Anger-Driven-Development. Meaning: do those things which makes people the least angry and prioritize addressing the things that make people the most angry. It turns out anger can be a useful prioritization vector; especially if you have clients who might just be angry enough to take their money elsewhere, or if coworkers / AI are still following the wrong practices and need incentive to stop producing slop.

Leave a comment on “Driven Development”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article