10 ms·

DDD Is Overrated

109 points by mcp_ 6y ago

linsomniac 6y ago
Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.
- HighlandSpring 6y ago
  Something tells me that in 2021 a lot more people will identify DDD to mean Domain-Driven Design than the concept that you mentioned
  - cozzyd 6y ago
    "man ddd" would disagree speaking of which, ddd is the only application I have installed that relies on motif...
    - linsomniac 6y ago
      Wow, Motif. Speaking of overrated... I had mostly blocked it out of my head.
  - coldtea 6y ago
    Your comment is a little funny because Domain-Driven Design is a concept, whereas DDD is an actual software that has existed for decades (a GDB front-end)....
  - buzzerbetrayed 6y ago
    Something tells me that even more people would identify Domain-Driven Design as Domain-Driven Design.
  - bjohnson225 6y ago
    You’re probably right, but it’s still better to spell it out in the title when a good percentage of readers will either be unfamiliar or think of something else.
  - kristopolous 6y ago
    I was literally introduced to that term with this article while I've been using ddd off and on for 20 years Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality. Like this from wikipedia: "An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux. People on other teams won't be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other." I mean holy hell, did a markov chain write that? Let me translate: "yo, some specs are more locked down than others so try to make the code more flexible for the parts that are likely to change" that's it. In my experience people that wrap simple stuff in academic potpourri get absolutely nothing done and generate really defective bloated software at very high cost because their code is written in the same way: simple things done in confusing and incomprehensible ways. It's as if someone covered something as dumb as rocks with the maximum amount of bullshit possible where you can still just barely translate it to comprehensible English. I'm surprised there's no set theory equations in that wikipedia page, maybe a bit of lambda calculus. We should get on that. In fact, let's make a tool where you define your contexts in Haskell and then run it over your code like a linter to generate GraphML files so someone can run it through graphviz and print it out to put it on their wall to have in the background during their stand-ups so they can make themselves look super professional. Who cares if your deadlines slipped another month, you're clearly an authority! Other industries, like hairbraiding require certificates and licenses to protect their jobs. In software, instead, apparently, some people ornately festoon simple things with fancy language and hide it behind acronym soup. Go work on harder problems, seriously
    - FieryTransition 6y ago
      Agreed, sounds like they are trying to say that two people in different settings can make changes without understanding the reasons. It could also be summed up with, "go talk to each other"
      - kristopolous 6y ago
- FieryTransition 6y ago
  Wow, that's ancient, the built in graphic plotting feature seems nice though https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/
- thetopher 6y ago
  I was thinking of the debugger too. I was also surprised to see it described as “overrated” since it’s ratings have never been that good.
- anothernewdude 6y ago
  That buggy thing is also probably overrated. I'm just not sure how people rate it.
- deleted 6y ago
  [deleted]
- andi999 6y ago
  I thought it meant Data Driven Design.....
- kenniskrag 6y ago
  naming is hard :D
  - kgwgk 6y ago
    :DDD
- mixmastamyk 6y ago
  I was thinking of a fully digital audio recording, digital mixing, and digital mastering. :-) https://en.wikipedia.org/wiki/SPARS_code https://en.wikipedia.org/wiki/SPARS_code
- SAI_Peregrinus 6y ago
  Nor with Documentation Driven Development.
rtpg 6y ago
One thing I heard recently, that I found pretty true when role-playing in my mind, is that most of the design methodologies get like... 90% of their value from forcing _a_ methodology onto people. The barebones "top-down"/"bottom-up" strategies most of us start up with is basically no good at forcing us to plan things out. But other strategies cause design errors to bubble up more quickly, so we can fix them, ship stuff that's right the first time etc. Anyways I guess I just feel like you can totally mix-and-match design methodologies to your problem space, so long as you're actually applying it seriously enough (and have some agreement with stakeholders about it). But I do feel like too much discussion on these topics focus on failure cases and "false practice", and don't really end with actionable advice.
- LudwigNagasena 6y ago
  I have read similar thoughts on psychology. Makes sense to me.
- rramadass 6y ago
  See the paper A Rational Design Process: How and Why to Fake it by David Parnas for the origins of the idea. - https://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
fattire 6y ago
Was I alone in reading this as Dalton's Disk Disintegrator being overrated?
- deleted 6y ago
  [deleted]
- stevejb 6y ago
  I thought "Diners, Drive-ins, and Dives"
02020202 6y ago
tl;dr but i wholeheartedly disagree. i can live without the lingo but the concepts are incredibly important. especially in large and complex projects. even though, in essence, it is all merely about encapsulation of data and actions that can be performed with/on them within context. it is good to have some general understanding of what is actually being done, conceptually. and having a philosophy with a name helps.
- HelloNurse 6y ago
  DDD principles are very helpful and "robust" but they address, specifically, untangling complex domains and requirements: sometimes it's the main software design challenge, but often other aspect of architecture that DDD doesn't have a lot to say about are much more difficult and/or important. For example, from a domain driven point of view Awk operates on a simple structural hierarchy of input and output files, lines and fields; designing a nice DSL around the obvious operations on these entities is clearly a much greater achievement than designing (or rather postulating) this model.
scoopertrooper 6y ago
It seems that their primary gripe relates to the naming of certain concepts. The article does not support the headline.
Toine 6y ago
If anything, i find that DDD is underrated and underused. But i can totally imagine projects where it goes completely over the top, like anything (frameworks, patterns, microservices, Redux -oh god Redux-, whatever) Happened the exact same thing with agility when it became Agile™
- pm 6y ago
  Sounds like the difference between agile and Agile. It helps to understand the domain when you're architecting a solution, but I didn't realise there was an extended nomenclature around it. I thought it was just a conceptual phrase.
- deleted 6y ago
  [deleted]
enriquto 6y ago
It was a great debugger in its time, with some unique features. True, its development was abandoned at long time ago, but saying that it is "overrated" seems a bit unfair.
- 29athrowaway 6y ago
  The article is about Domain Driven Delopment, not the ddd debugger.
franciscop 6y ago
On the other hand, "Documentation Driven Design" is definitely underrated and an excellent way to end up with a very nice API.
- goatinaboat 6y ago
  Documentation Driven Design Or “literate programming”
- einpoklum 6y ago
  > definitely underrated Good documentation is under-rated; not sure about designing via the documentation. > excellent way to end up with a very nice API. My experience suggests otherwise. I've found that both the code and the documentation "write themselves" at different points of development, progressing logically until they hit some snag or question-mark, with each of them effecting the other side in somewhat unexpected ways - so that working on just one side first is not the right thing to do.
  - franciscop 6y ago
    Sure you might not be able to write 100% of the documentation in one go and then the code, but AFAIK that's neither the goal or the intention of DDD, it's more like "document a bit, write a bit, repeat". The way I do it is first write a draft of the documentation, of how I want the API to look like. Then check if that basic code is possible (which I can predict most of the times based on experience), then write some more docs or methods. When writing a lib I normally already know where I want to use it, so I can put example snippets from how I want to use it as the documentation first and then try to implement those methods. Examples of libraries I've written mostly this way: - https://github.com/franciscop/brownies https://github.com/franciscop/brownies - https://github.com/franciscop/files https://github.com/franciscop/files - https://github.com/franciscop/backblaze https://github.com/franciscop/backblaze
stevebmark 6y ago
Better article: https://dev.to/cheetah100/domain-driven-disaster-147i https://dev.to/cheetah100/domain-driven-disaster-147i The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what "domain" they fall into. Nevermind that "domain" is basically undefined and can mean many different concepts and different types of concepts. DDD has some decent and good ideas, and is over extended to "this is how you should set up everything." Build more platforms where the domain logic exists in user land, not in code land. Everyone will be more productive for it. The book Domain Driven Design is also terribly written. Good ideas written by someone who should not communicate with humans.
- stepbeek 6y ago
  I love technical reading but found DDD a really hard book to get through. I've been meaning to read the Vaughn Vernon books to figure out if they're an easier read for when I feel like I need to refresh my memory.
  - xupybd 6y ago
    Have you tried Scott Wlaschin's book. It's a very easy read.
    - stepbeek 6y ago
      I haven't, is this the one? https://www.amazon.co.uk/Domain-Modeling-Made-Functional-Domain-Driven/dp/1680502549 https://www.amazon.co.uk/Domain-Modeling-Made-Functional-Dom...
      - xupybd 6y ago
        That is the one. It's also an introduction to structuring an F# application so it might not be for everyone but it's an easy read. Also I'd recommend getting it from here. https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func... Just because I personally like the pragprog site.
pachico 6y ago
This article says nothing about DDD and all about how the author is coping with its gaining traction. I myself find DDD a pilar I don't want to work with anymore.
hardwaresofton 6y ago
The author is a fan of DDD (despite the title) and so am I. In fact I'd argue that DDD is just about the only way that you could possibly do work that can be categorized as "systems design". You either do it with the knowledge of the common sticking points of DDD or you don't. If you're writing a subroutine in a device driver or some other similarly specific task, then you don't need to do design. You can be clever or not clever, but what you're doing is building a flexible solution. If you're designing a system, it necessarily operates in a domain (and/or creates it's own), and DDD is one of the best tools for trying to building language and feeling out where abstraction can/should be. What the author seems to be wary of (which I agree with) is the cargo cult and legion of consultants pushing it. This article is essentially "use the right tool for the job, it's not always DDD", and I agree with the premise... but DDD is amazing when it's done well you can build systems that are easy to understand, manipulate and extend.
NicoJuicy 6y ago
What he probably means ( he doesn't go into details), is that you can create a simple monolith without splitting up everything. Which is basically true. But as soon as you go more complex, you'll probably wish you'd used DDD from the start. DDD is gaining traction, not because it's good. But because it's compatible with microservices. As an aside, i also like how jgobard developped ContosoUniversity ( https://github.com/jbogard/ContosoUniversityDotNetCore https://github.com/jbogard/ContosoUniversityDotNetCore / https://github.com/jbogard/ContosoUniversity/tree/master/src/ContosoUniversity https://github.com/jbogard/ContosoUniversity/tree/master/src... ) with vertical slices and feature folders.
stepbeek 6y ago
This feels like clickbait. It seems like the conclusion is something like “DDD done well is really good, but not perfect” which I can’t take action on. Maybe a concrete example of when it doesn’t work well would help? I’ve understood DDD to essentially be “focus on the business and here are some helpers that might make you more effective in doing so.” Do others find it overly prescriptive?
sfvisser 6y ago
I’ve never explicitly used DDD, but I am convinced there is great value in having an obvious abstraction barrier between a domain core and your application and UI layer. It will allow you to pivot the UX quickly without compromising your core idea. However, I’m not entirely convinced this needs to be encoded in tech very rigidly. Especially not for starting projects. Just make sure the vision in in your head is clear and clearly communicated to the entire team. As long as you know what you’re building ‘conceptually’ the chance of your code base becoming a mess is way less likely. With every line of code you need to know/feel either ‘this is core to our product/domain’ or ‘this might change in a year or so’. All the DDD/solid/kiss/services whatever paradigms are secondary to having a clear tech and product vision.
- notretarded 6y ago
  But you only know that through experience of developing against said practices...
Jach 6y ago
"XDD" for all X is overrated, in the sense that the ideas attract adherents who use them as the hammer for all nail-looking things. Yet the best way to present any XDD principles is to ignore the rest of the world and alternative approaches, otherwise you'll get bogged down in all the qualifications and exceptions and lose the central thread of what you're trying to communicate. The article is probably correct that bringing in DDD specialists on every design question is a mistake -- the use of DDD specialists ought to be to teach designers another way of doing design, then leave it up to them whether to apply it case-by-case. Same thing with TDD, the other D(data)DD, etc. The best DDD-related thing I've read is the paper "Programming as if the domain (and performance) mattered": https://drive.google.com/file/d/0B59Tysg-nEQZSXRqVjJmQjZyVXc/view https://drive.google.com/file/d/0B59Tysg-nEQZSXRqVjJmQjZyVXc... One of the lessons I took from it is that too often as programmers we look at a problem and immediately try to transform it to some other problem, typically in a more abstract domain. Often this is fruitful, and our formal education (not to mention whiteboard-hazing interview practices) centers around pounding this into our heads with reusable data structures and algorithms. But also often it leads to something harder to evolve, not as fit for the original purpose, and more confusing (especially to those unfamiliar with the abstractions used). If DDD does nothing but make us challenge that default mode of thought and consider not doing problem transformation immediately every time, it's a worthwhile endeavor. Another resource I widely recommend is the book Thinking Forth (http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/) It has many lessons applicable today on software design, including some useful thoughts on a program's "lexicon" that are somewhat DDD-related.
- radicalbyte 6y ago
  You need to understand the context that birthed DDD. It was a reaction to the model of building business logic into UI event handlers which was pushed hard at the time by the Visual Basic (and java equivalent) crowd in businesses. Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it. I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't Fowler.
  - huseyinkeles 6y ago
sarvasana 6y ago
Not even going to read it, because of the stupid click bait title.
deleted 6y ago
[deleted]
namelosw 6y ago
My organization was in the hype about DDD for years, so I practiced it for quite some time. I would say many parts of it is overrated. But there's still great parts. Here's what I learned: 1. It's a specific version of Model-driven Architecture. And the idea is very close to Hexagonal Architecture, Clean Architecture 2. There are a lot of cases when it's not worth it. If you don't have the vision to evolve your system for more than 3 years just forget about it. 3. Strategic design is more important than tactical design. You can adopt the former without the latter. If you only adopt the latter it doesn't help. 4. You don't have to adopt Microservice combined with DDD. 5. Start with coarse-grained Bounded Contexts if you're not experienced. Incorrectly fine-grained Bounded Context is simply painful. The Good: 1. Ubiquitous languages. Even if you're not doing DDD it's a very good idea to keep in mind. 2. Strategic design. Microservices usually creates more problems than it solves, the idea of splitting Bounded Contexts helps to ease some pain of building Microservices. 3. The Aggregate. If you're doing tactical design, pay most attention to the Aggregate design. The Bad: 1. Tactical design, the jargons like the Repositories, Domain Service, etc. IMO It's better to do the strategic stuff only, draw the Bounded Context, and let the autonomous teams do the implementation and forget the tactical stuff. They'll be motivated, feel fulfilled, and willing to improve the architecture of the fraction for themselves. In contrast to the Wizard vs Grunts (the Model Scientist vs Implementation Engineers) relations that are often seen in the financial industry. 2. The tactical jargons IMO are transient. They'll probably be starting to die out in a decade, just like most of the patterns described in the 'Patterns of Enterprise Application Architecture' from Martin Fowler. The Ugly: 1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream<User> or Flux<User>, unless you are using advanced languages like Scala and can parametrize them as TMonad<User> 2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model - if you're doing a traditional HTTP request/response Web project, your model will likely be a request/response one. If you think you're dreaming that you can use the same model for a real-time WebSocket project, or even a conflict-free collaborative project, good luck. You can build a real-time model in the first place, but it would be much more expensive. 3. The Repository pattern and the Aggregate pattern are like a trade-off to each other. The Aggregate wants to be rich and contain more domain logic, while the Repository stops them from being rich. As a comparison, the Active Record is much easier to be rich compared to the Repository, but it defeats the goal of being infrastructure agnostic. So if you're convinced you're going to do Web-only you can switch to Active Record + Aggregate rather than Repository. Just like 'Rails IS your application' according to DHH.
ktpsns 6y ago
And I thought this article was about the Data Display Debugger https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/ :D
- m463 6y ago
  Me too. I think it is quite old too, going back to 80's?
dman 6y ago
I came here expecting a critique of the DDD debugger :(
PostThisTooFast 6y ago
DDD never made sense. You HAVE to have a digital master, so the last letter will always be D. Only the first two letters tell you anything: digital recording, digital mix.
metanonsense 6y ago
Like many things that have the potential to make you feel clever, e.g. machine learning, functional programming, DDD can easily be overused / used for the wrong reasons, at least if it's not mastered to a certain level. When I first learned about DDD in 2008 or so, I was so proud of myself that each and every service was DDDified, which really put a huge mental burden on me and my team. It is not only that you have to think really deeply about your domain (which is usually a good thing) but you often come to a point where doing things the DDD way means a lot more work, e.g. creating Anti-Corruption Layers between bounded contexts. I spent so much time researching if I do things correctly and if the acknowledged prophets consider a design decision acceptable that coding started to hurt. At some point however - and I think this what happens whenever you master something sufficiently - the penny dropped that the subtitle of the Eric Evans book "Tackling complexity in the heart of the software" really meant something: that DDD was a method for building complex software. The book itself - if you read it carefully as I did many years later - says explicitly that you should not use DDD for most parts of your system but only complex "core domains". Nowadays, I am designing most services as "Transaction Scripts" again. Without feeling guilty.
zn44 6y ago
This is a perfect hn, reddit blog post. Controversial title catching points even if people don't read it. Simple contents that are easy to disagree with and broad topic that has a lot of meta. Karma production machine
hotcrossbunny 6y ago
I think it is often more helpful to ask the question "To what extent is XDD useful in context Y?". This firstly shifts the discussion away from whether something is universally good or bad (the space of bandwagon riders and hype curve surfers), and secondly avoids trying to comment on what one believes to be the popular opinion at some particular point in time. Perhaps the difficulty tho is that DDD in particular is a collection of ideas that I would opine might have quite different profiles in terms of both their applicability, and range of design scope. Ubiquitous Naming seems like its pretty widely applicable, and by its very nature is about building consensus within teams, whereas Repository, Factory, Service, Aggregate feel like they could be the dishes served up at some Object Oriented dinner party where the guests could quite justifiably argue long into the night about what the best model design should be.
ChicagoDave 6y ago
I think this article skips the most important aspect of DDD. Reducing Complexity. If you’re building simple systems, you don’t need DDD and Evans has always been clear about that. But when you have a complex system, using DDD to “pull it apart” is highly effective. What you build from the parts is subject to that rule as well. If you end up with ten boundaries and some of them are simple, use simple tools. DDD isn’t a religion. It’s meant to get architects to stop designing monoliths that we know have costly lifespans. It’s also meant to get us modeling with our business partners with tools like Event Storming and truly understanding strategic opportunities. DDD isn’t just about root aggregates and value objects. It’s a communication tool and a pretty damn good one.
mathiasverraes 6y ago
These articles are pretty much impossible to disagree with, because they follow the same pattern. Every tool, concept, or technology, that aims to address a common need, will eventually reach the point in their adoption curve where an author publishes a hot take. §1 Clickbait title §2 Tool X is popular. I'm a fan. Tool X is useful. §3 It annoys me that everybody(1) treats it as the golden hammer. A single tool is not enough. §4 There are other tools. We can even make more tools. The best Tool X users use many other tools. You can't shoehorn all problems into Tool X. §5 Conclusion: Not all things require Tool X. (1) The term "Everybody" is used, because the author doesn't want to name the individuals or group that caused the annoyance. It is definitely a pattern because if you’ve been around tech, you’ve read numerous of these articles. I doubt they achieve their goal. I think we need ways to help people avoid golden hammers, without merely pointing at the hammer. Interestingly, Eric Evans’ work includes heuristics on when not to use DDD, and a call to action to find many more patterns than the ones he lists :-)
twirlock 6y ago
People talk about DDD and mean two mutually exclusive things depending on the scenario. It's either an excuse to have domain concepts pervade your whole stack or it's a description of clearly labeling your models. The prior seems like a naive, bad idea, especially when used with traditional OOP.
systemvoltage 6y ago
Author talks about how DDD is overrated and gives a couple of arguments about nomenclature. The real issue seems to be in plain sight in the article: > But I’m annoyed by the fact that recently, it seems that any time somebody talks about how to architect system or service boundaries, or even just mentions non-technical design, everybody feels compelled to bring in the DDD experts That's the issue, their own experience has been terrible but I don't see any specifics about why domain driven design is terrible. Provide an example. Go through the rigor of your arguments. Show us some code, something concrete, tell us a story about how it was painful to them and what was the impact - whatever is needed to make a strong argument. The problem with articles like this is people read up on it, make their mind, and now you have a sloth of people converted to "Anti-DDD religion" will become painful to deal with at work because they read up some HN article about how DDD is overrated. It gets stuck in their minds like cereal in an empty milk bowl. I expect more from the author after saying "There, I said it." Totally ok to be anti-DDD, would love to hear more though.
donzampano 6y ago
DDD has the same foundation as Agile: Complex problems (domains) require explorative and iterative aproaches (like science always did), complicated or simple domains don't need that. And if you don't know the problem - then don't start doing anything. If you don't understand yourself well enough and cannot isolate a logical model, than stop, too. For me, that's both timeless wisdom, and nothing special.
scott_w 6y ago
I’m a bit late to the party on this but the article fundamentally misunderstands DDD. DDD explicitly doesn’t concern itself with implementation details. It doesn’t have an opinion on DB servers, how you should partition data, etc. DDD is a way of modelling your business logic. Your domain doesn’t care about databases or servers, these are details at the edges of your application. If your domain does need to care about the details of how it runs on servers and databases, then perhaps DDD is not the right tool for the job.

109 points by mcp_ 6y ago

Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.

HighlandSpring 6y ago
Something tells me that in 2021 a lot more people will identify DDD to mean Domain-Driven Design than the concept that you mentioned
- cozzyd 6y ago
  "man ddd" would disagree speaking of which, ddd is the only application I have installed that relies on motif...
  - linsomniac 6y ago
    Wow, Motif. Speaking of overrated... I had mostly blocked it out of my head.
- coldtea 6y ago
  Your comment is a little funny because Domain-Driven Design is a concept, whereas DDD is an actual software that has existed for decades (a GDB front-end)....
- buzzerbetrayed 6y ago
  Something tells me that even more people would identify Domain-Driven Design as Domain-Driven Design.
- bjohnson225 6y ago
  You’re probably right, but it’s still better to spell it out in the title when a good percentage of readers will either be unfamiliar or think of something else.
- kristopolous 6y ago
  I was literally introduced to that term with this article while I've been using ddd off and on for 20 years Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality. Like this from wikipedia: "An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux. People on other teams won't be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other." I mean holy hell, did a markov chain write that? Let me translate: "yo, some specs are more locked down than others so try to make the code more flexible for the parts that are likely to change" that's it. In my experience people that wrap simple stuff in academic potpourri get absolutely nothing done and generate really defective bloated software at very high cost because their code is written in the same way: simple things done in confusing and incomprehensible ways. It's as if someone covered something as dumb as rocks with the maximum amount of bullshit possible where you can still just barely translate it to comprehensible English. I'm surprised there's no set theory equations in that wikipedia page, maybe a bit of lambda calculus. We should get on that. In fact, let's make a tool where you define your contexts in Haskell and then run it over your code like a linter to generate GraphML files so someone can run it through graphviz and print it out to put it on their wall to have in the background during their stand-ups so they can make themselves look super professional. Who cares if your deadlines slipped another month, you're clearly an authority! Other industries, like hairbraiding require certificates and licenses to protect their jobs. In software, instead, apparently, some people ornately festoon simple things with fancy language and hide it behind acronym soup. Go work on harder problems, seriously
  - FieryTransition 6y ago
    Agreed, sounds like they are trying to say that two people in different settings can make changes without understanding the reasons. It could also be summed up with, "go talk to each other"
    - kristopolous 6y ago
FieryTransition 6y ago
Wow, that's ancient, the built in graphic plotting feature seems nice though https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/
thetopher 6y ago
I was thinking of the debugger too. I was also surprised to see it described as “overrated” since it’s ratings have never been that good.
anothernewdude 6y ago
That buggy thing is also probably overrated. I'm just not sure how people rate it.
deleted 6y ago
[deleted]
andi999 6y ago
I thought it meant Data Driven Design.....
kenniskrag 6y ago
naming is hard :D
- kgwgk 6y ago
  :DDD
mixmastamyk 6y ago
I was thinking of a fully digital audio recording, digital mixing, and digital mastering. :-) https://en.wikipedia.org/wiki/SPARS_code https://en.wikipedia.org/wiki/SPARS_code
SAI_Peregrinus 6y ago
Nor with Documentation Driven Development.

rtpg 6y ago

One thing I heard recently, that I found pretty true when role-playing in my mind, is that most of the design methodologies get like... 90% of their value from forcing _a_ methodology onto people. The barebones "top-down"/"bottom-up" strategies most of us start up with is basically no good at forcing us to plan things out. But other strategies cause design errors to bubble up more quickly, so we can fix them, ship stuff that's right the first time etc. Anyways I guess I just feel like you can totally mix-and-match design methodologies to your problem space, so long as you're actually applying it seriously enough (and have some agreement with stakeholders about it). But I do feel like too much discussion on these topics focus on failure cases and "false practice", and don't really end with actionable advice.

LudwigNagasena 6y ago
I have read similar thoughts on psychology. Makes sense to me.
rramadass 6y ago
See the paper A Rational Design Process: How and Why to Fake it by David Parnas for the origins of the idea. - https://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...

fattire 6y ago

Was I alone in reading this as Dalton's Disk Disintegrator being overrated?

deleted 6y ago
[deleted]
stevejb 6y ago
I thought "Diners, Drive-ins, and Dives"

02020202 6y ago

tl;dr but i wholeheartedly disagree. i can live without the lingo but the concepts are incredibly important. especially in large and complex projects. even though, in essence, it is all merely about encapsulation of data and actions that can be performed with/on them within context. it is good to have some general understanding of what is actually being done, conceptually. and having a philosophy with a name helps.

HelloNurse 6y ago
DDD principles are very helpful and "robust" but they address, specifically, untangling complex domains and requirements: sometimes it's the main software design challenge, but often other aspect of architecture that DDD doesn't have a lot to say about are much more difficult and/or important. For example, from a domain driven point of view Awk operates on a simple structural hierarchy of input and output files, lines and fields; designing a nice DSL around the obvious operations on these entities is clearly a much greater achievement than designing (or rather postulating) this model.

scoopertrooper 6y ago

It seems that their primary gripe relates to the naming of certain concepts. The article does not support the headline.

Toine 6y ago

If anything, i find that DDD is underrated and underused. But i can totally imagine projects where it goes completely over the top, like anything (frameworks, patterns, microservices, Redux -oh god Redux-, whatever) Happened the exact same thing with agility when it became Agile™

pm 6y ago
Sounds like the difference between agile and Agile. It helps to understand the domain when you're architecting a solution, but I didn't realise there was an extended nomenclature around it. I thought it was just a conceptual phrase.
deleted 6y ago
[deleted]

enriquto 6y ago

It was a great debugger in its time, with some unique features. True, its development was abandoned at long time ago, but saying that it is "overrated" seems a bit unfair.

29athrowaway 6y ago
The article is about Domain Driven Delopment, not the ddd debugger.

franciscop 6y ago

On the other hand, "Documentation Driven Design" is definitely underrated and an excellent way to end up with a very nice API.

goatinaboat 6y ago
Documentation Driven Design Or “literate programming”
einpoklum 6y ago
> definitely underrated Good documentation is under-rated; not sure about designing via the documentation. > excellent way to end up with a very nice API. My experience suggests otherwise. I've found that both the code and the documentation "write themselves" at different points of development, progressing logically until they hit some snag or question-mark, with each of them effecting the other side in somewhat unexpected ways - so that working on just one side first is not the right thing to do.
- franciscop 6y ago
  Sure you might not be able to write 100% of the documentation in one go and then the code, but AFAIK that's neither the goal or the intention of DDD, it's more like "document a bit, write a bit, repeat". The way I do it is first write a draft of the documentation, of how I want the API to look like. Then check if that basic code is possible (which I can predict most of the times based on experience), then write some more docs or methods. When writing a lib I normally already know where I want to use it, so I can put example snippets from how I want to use it as the documentation first and then try to implement those methods. Examples of libraries I've written mostly this way: - https://github.com/franciscop/brownies https://github.com/franciscop/brownies - https://github.com/franciscop/files https://github.com/franciscop/files - https://github.com/franciscop/backblaze https://github.com/franciscop/backblaze

stevebmark 6y ago

Better article: https://dev.to/cheetah100/domain-driven-disaster-147i https://dev.to/cheetah100/domain-driven-disaster-147i The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what "domain" they fall into. Nevermind that "domain" is basically undefined and can mean many different concepts and different types of concepts. DDD has some decent and good ideas, and is over extended to "this is how you should set up everything." Build more platforms where the domain logic exists in user land, not in code land. Everyone will be more productive for it. The book Domain Driven Design is also terribly written. Good ideas written by someone who should not communicate with humans.

stepbeek 6y ago
I love technical reading but found DDD a really hard book to get through. I've been meaning to read the Vaughn Vernon books to figure out if they're an easier read for when I feel like I need to refresh my memory.
- xupybd 6y ago
  Have you tried Scott Wlaschin's book. It's a very easy read.
  - stepbeek 6y ago
    I haven't, is this the one? https://www.amazon.co.uk/Domain-Modeling-Made-Functional-Domain-Driven/dp/1680502549 https://www.amazon.co.uk/Domain-Modeling-Made-Functional-Dom...
    - xupybd 6y ago
      That is the one. It's also an introduction to structuring an F# application so it might not be for everyone but it's an easy read. Also I'd recommend getting it from here. https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func... Just because I personally like the pragprog site.

pachico 6y ago

This article says nothing about DDD and all about how the author is coping with its gaining traction. I myself find DDD a pilar I don't want to work with anymore.

hardwaresofton 6y ago

The author is a fan of DDD (despite the title) and so am I. In fact I'd argue that DDD is just about the only way that you could possibly do work that can be categorized as "systems design". You either do it with the knowledge of the common sticking points of DDD or you don't. If you're writing a subroutine in a device driver or some other similarly specific task, then you don't need to do design. You can be clever or not clever, but what you're doing is building a flexible solution. If you're designing a system, it necessarily operates in a domain (and/or creates it's own), and DDD is one of the best tools for trying to building language and feeling out where abstraction can/should be. What the author seems to be wary of (which I agree with) is the cargo cult and legion of consultants pushing it. This article is essentially "use the right tool for the job, it's not always DDD", and I agree with the premise... but DDD is amazing when it's done well you can build systems that are easy to understand, manipulate and extend.

NicoJuicy 6y ago

What he probably means ( he doesn't go into details), is that you can create a simple monolith without splitting up everything. Which is basically true. But as soon as you go more complex, you'll probably wish you'd used DDD from the start. DDD is gaining traction, not because it's good. But because it's compatible with microservices. As an aside, i also like how jgobard developped ContosoUniversity ( https://github.com/jbogard/ContosoUniversityDotNetCore https://github.com/jbogard/ContosoUniversityDotNetCore / https://github.com/jbogard/ContosoUniversity/tree/master/src/ContosoUniversity https://github.com/jbogard/ContosoUniversity/tree/master/src... ) with vertical slices and feature folders.

stepbeek 6y ago

This feels like clickbait. It seems like the conclusion is something like “DDD done well is really good, but not perfect” which I can’t take action on. Maybe a concrete example of when it doesn’t work well would help? I’ve understood DDD to essentially be “focus on the business and here are some helpers that might make you more effective in doing so.” Do others find it overly prescriptive?

sfvisser 6y ago

I’ve never explicitly used DDD, but I am convinced there is great value in having an obvious abstraction barrier between a domain core and your application and UI layer. It will allow you to pivot the UX quickly without compromising your core idea. However, I’m not entirely convinced this needs to be encoded in tech very rigidly. Especially not for starting projects. Just make sure the vision in in your head is clear and clearly communicated to the entire team. As long as you know what you’re building ‘conceptually’ the chance of your code base becoming a mess is way less likely. With every line of code you need to know/feel either ‘this is core to our product/domain’ or ‘this might change in a year or so’. All the DDD/solid/kiss/services whatever paradigms are secondary to having a clear tech and product vision.

notretarded 6y ago
But you only know that through experience of developing against said practices...

Jach 6y ago

"XDD" for all X is overrated, in the sense that the ideas attract adherents who use them as the hammer for all nail-looking things. Yet the best way to present any XDD principles is to ignore the rest of the world and alternative approaches, otherwise you'll get bogged down in all the qualifications and exceptions and lose the central thread of what you're trying to communicate. The article is probably correct that bringing in DDD specialists on every design question is a mistake -- the use of DDD specialists ought to be to teach designers another way of doing design, then leave it up to them whether to apply it case-by-case. Same thing with TDD, the other D(data)DD, etc. The best DDD-related thing I've read is the paper "Programming as if the domain (and performance) mattered": https://drive.google.com/file/d/0B59Tysg-nEQZSXRqVjJmQjZyVXc/view https://drive.google.com/file/d/0B59Tysg-nEQZSXRqVjJmQjZyVXc... One of the lessons I took from it is that too often as programmers we look at a problem and immediately try to transform it to some other problem, typically in a more abstract domain. Often this is fruitful, and our formal education (not to mention whiteboard-hazing interview practices) centers around pounding this into our heads with reusable data structures and algorithms. But also often it leads to something harder to evolve, not as fit for the original purpose, and more confusing (especially to those unfamiliar with the abstractions used). If DDD does nothing but make us challenge that default mode of thought and consider not doing problem transformation immediately every time, it's a worthwhile endeavor. Another resource I widely recommend is the book Thinking Forth (http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/) It has many lessons applicable today on software design, including some useful thoughts on a program's "lexicon" that are somewhat DDD-related.

radicalbyte 6y ago
You need to understand the context that birthed DDD. It was a reaction to the model of building business logic into UI event handlers which was pushed hard at the time by the Visual Basic (and java equivalent) crowd in businesses. Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it. I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't Fowler.
- huseyinkeles 6y ago

sarvasana 6y ago

Not even going to read it, because of the stupid click bait title.

deleted 6y ago

[deleted]

namelosw 6y ago

My organization was in the hype about DDD for years, so I practiced it for quite some time. I would say many parts of it is overrated. But there's still great parts. Here's what I learned: 1. It's a specific version of Model-driven Architecture. And the idea is very close to Hexagonal Architecture, Clean Architecture 2. There are a lot of cases when it's not worth it. If you don't have the vision to evolve your system for more than 3 years just forget about it. 3. Strategic design is more important than tactical design. You can adopt the former without the latter. If you only adopt the latter it doesn't help. 4. You don't have to adopt Microservice combined with DDD. 5. Start with coarse-grained Bounded Contexts if you're not experienced. Incorrectly fine-grained Bounded Context is simply painful. The Good: 1. Ubiquitous languages. Even if you're not doing DDD it's a very good idea to keep in mind. 2. Strategic design. Microservices usually creates more problems than it solves, the idea of splitting Bounded Contexts helps to ease some pain of building Microservices. 3. The Aggregate. If you're doing tactical design, pay most attention to the Aggregate design. The Bad: 1. Tactical design, the jargons like the Repositories, Domain Service, etc. IMO It's better to do the strategic stuff only, draw the Bounded Context, and let the autonomous teams do the implementation and forget the tactical stuff. They'll be motivated, feel fulfilled, and willing to improve the architecture of the fraction for themselves. In contrast to the Wizard vs Grunts (the Model Scientist vs Implementation Engineers) relations that are often seen in the financial industry. 2. The tactical jargons IMO are transient. They'll probably be starting to die out in a decade, just like most of the patterns described in the 'Patterns of Enterprise Application Architecture' from Martin Fowler. The Ugly: 1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream<User> or Flux<User>, unless you are using advanced languages like Scala and can parametrize them as TMonad<User> 2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model - if you're doing a traditional HTTP request/response Web project, your model will likely be a request/response one. If you think you're dreaming that you can use the same model for a real-time WebSocket project, or even a conflict-free collaborative project, good luck. You can build a real-time model in the first place, but it would be much more expensive. 3. The Repository pattern and the Aggregate pattern are like a trade-off to each other. The Aggregate wants to be rich and contain more domain logic, while the Repository stops them from being rich. As a comparison, the Active Record is much easier to be rich compared to the Repository, but it defeats the goal of being infrastructure agnostic. So if you're convinced you're going to do Web-only you can switch to Active Record + Aggregate rather than Repository. Just like 'Rails IS your application' according to DHH.

ktpsns 6y ago

And I thought this article was about the Data Display Debugger https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/ :D

m463 6y ago
Me too. I think it is quite old too, going back to 80's?

dman 6y ago

I came here expecting a critique of the DDD debugger :(

PostThisTooFast 6y ago

DDD never made sense. You HAVE to have a digital master, so the last letter will always be D. Only the first two letters tell you anything: digital recording, digital mix.

metanonsense 6y ago

Like many things that have the potential to make you feel clever, e.g. machine learning, functional programming, DDD can easily be overused / used for the wrong reasons, at least if it's not mastered to a certain level. When I first learned about DDD in 2008 or so, I was so proud of myself that each and every service was DDDified, which really put a huge mental burden on me and my team. It is not only that you have to think really deeply about your domain (which is usually a good thing) but you often come to a point where doing things the DDD way means a lot more work, e.g. creating Anti-Corruption Layers between bounded contexts. I spent so much time researching if I do things correctly and if the acknowledged prophets consider a design decision acceptable that coding started to hurt. At some point however - and I think this what happens whenever you master something sufficiently - the penny dropped that the subtitle of the Eric Evans book "Tackling complexity in the heart of the software" really meant something: that DDD was a method for building complex software. The book itself - if you read it carefully as I did many years later - says explicitly that you should not use DDD for most parts of your system but only complex "core domains". Nowadays, I am designing most services as "Transaction Scripts" again. Without feeling guilty.

zn44 6y ago

This is a perfect hn, reddit blog post. Controversial title catching points even if people don't read it. Simple contents that are easy to disagree with and broad topic that has a lot of meta. Karma production machine

hotcrossbunny 6y ago

I think it is often more helpful to ask the question "To what extent is XDD useful in context Y?". This firstly shifts the discussion away from whether something is universally good or bad (the space of bandwagon riders and hype curve surfers), and secondly avoids trying to comment on what one believes to be the popular opinion at some particular point in time. Perhaps the difficulty tho is that DDD in particular is a collection of ideas that I would opine might have quite different profiles in terms of both their applicability, and range of design scope. Ubiquitous Naming seems like its pretty widely applicable, and by its very nature is about building consensus within teams, whereas Repository, Factory, Service, Aggregate feel like they could be the dishes served up at some Object Oriented dinner party where the guests could quite justifiably argue long into the night about what the best model design should be.

ChicagoDave 6y ago

I think this article skips the most important aspect of DDD. Reducing Complexity. If you’re building simple systems, you don’t need DDD and Evans has always been clear about that. But when you have a complex system, using DDD to “pull it apart” is highly effective. What you build from the parts is subject to that rule as well. If you end up with ten boundaries and some of them are simple, use simple tools. DDD isn’t a religion. It’s meant to get architects to stop designing monoliths that we know have costly lifespans. It’s also meant to get us modeling with our business partners with tools like Event Storming and truly understanding strategic opportunities. DDD isn’t just about root aggregates and value objects. It’s a communication tool and a pretty damn good one.

mathiasverraes 6y ago

These articles are pretty much impossible to disagree with, because they follow the same pattern. Every tool, concept, or technology, that aims to address a common need, will eventually reach the point in their adoption curve where an author publishes a hot take. §1 Clickbait title §2 Tool X is popular. I'm a fan. Tool X is useful. §3 It annoys me that everybody(1) treats it as the golden hammer. A single tool is not enough. §4 There are other tools. We can even make more tools. The best Tool X users use many other tools. You can't shoehorn all problems into Tool X. §5 Conclusion: Not all things require Tool X. (1) The term "Everybody" is used, because the author doesn't want to name the individuals or group that caused the annoyance. It is definitely a pattern because if you’ve been around tech, you’ve read numerous of these articles. I doubt they achieve their goal. I think we need ways to help people avoid golden hammers, without merely pointing at the hammer. Interestingly, Eric Evans’ work includes heuristics on when not to use DDD, and a call to action to find many more patterns than the ones he lists :-)

twirlock 6y ago

People talk about DDD and mean two mutually exclusive things depending on the scenario. It's either an excuse to have domain concepts pervade your whole stack or it's a description of clearly labeling your models. The prior seems like a naive, bad idea, especially when used with traditional OOP.

systemvoltage 6y ago

Author talks about how DDD is overrated and gives a couple of arguments about nomenclature. The real issue seems to be in plain sight in the article: > But I’m annoyed by the fact that recently, it seems that any time somebody talks about how to architect system or service boundaries, or even just mentions non-technical design, everybody feels compelled to bring in the DDD experts That's the issue, their own experience has been terrible but I don't see any specifics about why domain driven design is terrible. Provide an example. Go through the rigor of your arguments. Show us some code, something concrete, tell us a story about how it was painful to them and what was the impact - whatever is needed to make a strong argument. The problem with articles like this is people read up on it, make their mind, and now you have a sloth of people converted to "Anti-DDD religion" will become painful to deal with at work because they read up some HN article about how DDD is overrated. It gets stuck in their minds like cereal in an empty milk bowl. I expect more from the author after saying "There, I said it." Totally ok to be anti-DDD, would love to hear more though.

donzampano 6y ago

DDD has the same foundation as Agile: Complex problems (domains) require explorative and iterative aproaches (like science always did), complicated or simple domains don't need that. And if you don't know the problem - then don't start doing anything. If you don't understand yourself well enough and cannot isolate a logical model, than stop, too. For me, that's both timeless wisdom, and nothing special.

scott_w 6y ago

I’m a bit late to the party on this but the article fundamentally misunderstands DDD. DDD explicitly doesn’t concern itself with implementation details. It doesn’t have an opinion on DB servers, how you should partition data, etc. DDD is a way of modelling your business logic. Your domain doesn’t care about databases or servers, these are details at the edges of your application. If your domain does need to care about the details of how it runs on servers and databases, then perhaps DDD is not the right tool for the job.