6 ms·

I'll be honest, I view DDD as an org smell at this point. Every place I've encountered it, it was attempting to fix with process something that needed to be fix

I'll be honest, I view DDD as an org smell at this point. Every place I've encountered it, it was attempting to fix with process something that needed to be fixed with culture. That is, in places where "product understands the problem it wants to solve, and wants to engage with dev about it", and the engineering manager cared about the problem, and worked to get the team to understand and care about it, pitch potential solutions, and then deliver them in a prioritized manner, DDD wasn't even suggested. It just wasn't necessary; all the useful artifacts from it happened naturally because product and dev were so closely aligned. In the places where product didn't really know what problem they wanted to solve, and didn't want to engage with dev, and the org pressures were around documentation and gating, DDD was heralded as the cure-all that would get everything flowing smoothly, while solving many of the documentation and gating needs. It didn't do any of that.

camgunz 5y ago
Yeah I'll pile on here. DDD is a process fix, not a tech fix, and broadly unless you're using Java, you can't implement it very well. Or, you'll find that you're actually using it without knowing it. Case in point, we used Django at my last gig and Django basically is DDD (apps are domains, models are entities, etc). We then started implementing DDD and essentially built weirdly named Django on Django, with way worse performance--and now any engineer we hired had to know two things (Django _and_ DDD). I wouldn't necessarily blame DDD here though? Mostly the problems were we didn't have reasonable performance metrics. Our CTO thought we had a problem, then he decided we should implement DDD, then we implemented it, and he thought we no longer had a problem. But there were no numbers to point to, we didn't know if we were delivering features faster/slower, if our PRs were smaller/larger, if our defect rate was higher/lower. We _did_ know our app was slower, because it would timeout (ha), but that's kind of the worst way to find that out. But, generally my argument here is: Think of any baller software project you use. Is it VS Code? Chrome? GitHub? NGINX? Do any of these use DDD?
- jen20 5y ago
  DDD does not have a canonical implementation in the form you suggest - the modern consensus is that it is a problem space tool, not a solution space one. The meat of DDD is in the strategic design section, not the structural patterns which have clearly not evolved for the modern world. And no, none of those pieces of software listed use DDD, because none of them are business applications, and it would be very inappropriate for them to do so.
  - camgunz 5y ago
    In fairness though, I think "business application" doesn't have a clear definition. What separates them from client/server games? Suddenly yeah, now you're thinking about CQRS, reading account information from a database, serializing state--certainly sounds like a business application to me. Doesn't Chrome connect to Google servers that talk to databases? Isn't VS Code an Electron app that talks to backend services? I would argue that thinking about things in terms of application type isn't that useful. Rather, I've gotten more mileage from thinking about the lower-level problems. Like do we have to deal with concurrent modification, do our users span timezones, blah blah blah. These things give me more to work with when designing an application than like, whatever its "type" is.
- hardwaresofton 5y ago
  So this is part of the problem with DDD, there are so many ideas about what DDD is that it's hard to boil it down. Trying to measure without metrics and then blaming DDD sounds very silly. If performance is the issue, then measure and improve it -- adding more layers of abstraction (it really depends on what "implementing DDD" means) is generally not the way to do that. ORMs are DDD (ORMs are also bad), but you can also consider SQL as DDD (declarative queries are a way of dealing with only domain logic), and so is the generic serialization problem (so you can use gRPC or JSON, let's say). Note that DDD is NOT creating DSLs -- I'm pretty against DSLs for most things because usually the problem space expands for super general DSLs. People tend to go overboard with DDD though. So much so that there are some people who have snapped back the other way and think that basically nothing should be generic.
  - tomnipotent 5y ago
    > ORMs are DDD (ORMs are also bad), but you can also consider SQL as DDD I'm not convinced we're all talking about the same DDD, because ORMs or SQL are not DDD in any context other than being implementation details on a project (unless your domain is specifically providing an ORM or SQL product).
    - hardwaresofton 5y ago
      Well it depends on how you look at it. So ORMs definitely are, just look at the definition and that's exactly what ORMs (with class mappers) usually let you do. Thinking in terms of User instead of DatabaseRow<T> is certainly DDD. What I was wrong about was that SQL isn't really DDD. I didn't realize the colloquial definition[0] is so strict as to call out classes. [0]: https://en.wikipedia.org/wiki/Domain-driven_design https://en.wikipedia.org/wiki/Domain-driven_design
      - aszen 5y ago
        ORMs have nothing to do with DDD, they merely provide objects which map to your database tables. The crux of DDD is to model your application in a domain centric way, what that means is using domain concepts in your business objects instead of just getters and setters. One of the most important things is separating your domain from infrastructure and the ui around it. This can be achieved in a variety of ways, with and without an orm. DDD encourages application designers to start with the domain first, and build the infrastructure and ui around it later on. It changes the language we speak of during designing application, instead of asking whether to use SQL or NoSQL say, you design your domain first + the operations around it and afterwards think about what's the ideal infrastructure to use.
- _Understated_ 5y ago
  > Think of any baller software project you use. Is it VS Code? Chrome? GitHub? NGINX? Do any of these use DDD? That's a fantastic question. Something I've often wondered too. I'm a fan of DDD but it's like saying "I'm a fan of hammers"... hammers have their place and there is no other tool like them... for the thing they are good at. I used to be all "omg <FoM> is the only way to do things" but nowadays, I tend not to get too hung up on prescribed, named processes and aim for decoupling where it makes sense (for the most part!)
  - arethuza 5y ago
    Speaking of hammers and software design reminds me of a classic: https://web.archive.org/web/20180924092925/http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 https://web.archive.org/web/20180924092925/http://discuss.jo... "Nobody really buys hammers anymore. They're kind of old fashioned."
- robjan 5y ago
  > Chrome? GitHub? NGINX? Do any of these use DDD? These are not business applications, they are general purpose software. A business application is something made to model a business process or an entire business, such as an ERP. DDD is perfect for this.
  - Thaxll 5y ago
    Any software can be described as a business application, for Chrome it could be that I want a software that's able to browse and render web pages.
    - deleted 5y ago
      [deleted]
hardwaresofton 5y ago
So I'm not really sure what DDD looks like in those kind of orgs at this point -- DDD is purely a code organization thing -- it's an implementation detail, so I'm not sure how it would show up in a product/dev discussion scenario... The fact that a prodcut team doesn't know what it wants to solve has nothing to do with DDD, other than maybe asking the devs to make the solution as generic as possible (?) -- but that's a bad situation whether you're using DDD or not. I probably just can't understand this because I haven't had this experience
- lostcolony 5y ago
  That's fair, but I will point out that that's a bit of a "no true scotsman" argument, if it's meant as an argument. Regardless, I'm not really saying anything about DDD; just my experience of organizations saying they're using it. They may indeed be misusing it. They probably are, in fact; my whole point is that the orgs I've encountered that have figured out how to write software successfully don't say they use DDD (even if implicitly they do based on someone's definition of what DDD is), and the orgs I've encountered that say they use DDD to write software then execute very, very poorly, if at all, to the point I don't want to work for orgs that say they use DDD. I believe the cause of that experience to be that the orgs that have cultures that prioritize the right things to where product and dev align very rarely look to adopt new processes that purport to solve problems they already have solved, and the orgs that have cultures that create obstacles look to processes as silver bullets to address them. It's very likely akin to your comment about design patterns; a well built implementation may exhibit some design patterns, even without the author knowing that's what they are. A badly built implementation may look like someone had their gof4 book at hand and was looking for any possible excuse to use a pattern (and they're all named according, FooFactory, BarSingleton, so you can go "yep, they're using design patterns alright"). The latter isn't a judgement on design patterns, but the former may not find very much use for designating what is working for them as design patterns. I.e., it's not necessarily about what is actually in use, but what is being said is in use. My experience is that orgs that say they use DDD = avoid.
- lostcolony 5y ago
  Also, for how DDD would incorporate both dev and product, product (ostensibly) knows the domain, and needs to communicate it to dev to be able to design things. A logical follow-up, then, is Event Storming ( https://en.wikipedia.org/wiki/Event_storming https://en.wikipedia.org/wiki/Event_storming ) which came out of DDD, and explicitly lists out dev and domain experts as being involved. Which very much points at my earlier comment of trying to solve by process what should be natural from culture (i.e., are dev and product talking to each other).
deleted 5y ago
[deleted]
jacobmoe 5y ago
> all the useful artifacts from it happened naturally because product and dev were so closely aligned. Aren't you just saying that DDD wasn't proposed as a solution to the problem because the problem didn't exist? Starting to jog is a smell that you're out of shape, if you were in shape you wouldn't need to start jogging. One of the ideas that DDD pushes is that product and dev should be closely aligned. The reason that's emphasized is that it isn't the case in a lot of organizations. Of course you could try to avoid all orgs with these kinds of problems (I haven't been able to, unfortunately), but the question is, if encountering an org that _does_ have problems, what solution would you propose?
- lostcolony 5y ago
  I am indeed saying DDD wasn't proposed as a solution to the problem because the problem didn't exist. I even call that out in the post you're responding to - "Every place I've encountered it, it was attempting to fix with process something that needed to be fixed with culture." And then expound how places with the right culture didn't see value in DDD, and places with poor culture tried to band-aid over it with DDD. As I comment elsewhere, that's not an indictment of DDD as a practice, just that when orgs seek to adopt it it's indicative of a problem, one that DDD won't fix. >>> Starting to jog is a smell that you're out of shape, if you were in shape you wouldn't need to start jogging. Let me rephrase that, since it's not 'starting to jog', but 'jogging'. Trying DDD (because of purported benefits) is different than continuing to use DDD (because of actualized benefits). So "jogging is a smell that you're out of shape; if you're in shape you won't be jogging". And that's patently false. What I think you're trying to say is that jogging will help keep in shape people in shape, and will help out of shape people get into shape as well, yes? Which would equate to "DDD can help effective software orgs stay effective, and ineffective software orgs become effective". Which is a reasonable claim, but one I've simply not seen; I've not encountered an effective software org that used it, and all the ones I've encountered that used it were ineffective, and, at least during my tenure there, remained so. >>> One of the ideas that DDD pushes is that product and dev should be closely aligned. It may try to push that idea, but it does nothing to help it occur. It's implicit, but no more than anything else software related (in that to build something the builders have to know what to build). Certainly, if you asked anyone, using any process, whether or not it's a good idea to have product and dev -unaligned-, they would say "of course not! As a practitioner of X I certainly believe they should be aligned".

camgunz 5y ago

Yeah I'll pile on here. DDD is a process fix, not a tech fix, and broadly unless you're using Java, you can't implement it very well. Or, you'll find that you're actually using it without knowing it. Case in point, we used Django at my last gig and Django basically is DDD (apps are domains, models are entities, etc). We then started implementing DDD and essentially built weirdly named Django on Django, with way worse performance--and now any engineer we hired had to know two things (Django _and_ DDD). I wouldn't necessarily blame DDD here though? Mostly the problems were we didn't have reasonable performance metrics. Our CTO thought we had a problem, then he decided we should implement DDD, then we implemented it, and he thought we no longer had a problem. But there were no numbers to point to, we didn't know if we were delivering features faster/slower, if our PRs were smaller/larger, if our defect rate was higher/lower. We _did_ know our app was slower, because it would timeout (ha), but that's kind of the worst way to find that out. But, generally my argument here is: Think of any baller software project you use. Is it VS Code? Chrome? GitHub? NGINX? Do any of these use DDD?

jen20 5y ago
DDD does not have a canonical implementation in the form you suggest - the modern consensus is that it is a problem space tool, not a solution space one. The meat of DDD is in the strategic design section, not the structural patterns which have clearly not evolved for the modern world. And no, none of those pieces of software listed use DDD, because none of them are business applications, and it would be very inappropriate for them to do so.
- camgunz 5y ago
  In fairness though, I think "business application" doesn't have a clear definition. What separates them from client/server games? Suddenly yeah, now you're thinking about CQRS, reading account information from a database, serializing state--certainly sounds like a business application to me. Doesn't Chrome connect to Google servers that talk to databases? Isn't VS Code an Electron app that talks to backend services? I would argue that thinking about things in terms of application type isn't that useful. Rather, I've gotten more mileage from thinking about the lower-level problems. Like do we have to deal with concurrent modification, do our users span timezones, blah blah blah. These things give me more to work with when designing an application than like, whatever its "type" is.
hardwaresofton 5y ago
So this is part of the problem with DDD, there are so many ideas about what DDD is that it's hard to boil it down. Trying to measure without metrics and then blaming DDD sounds very silly. If performance is the issue, then measure and improve it -- adding more layers of abstraction (it really depends on what "implementing DDD" means) is generally not the way to do that. ORMs are DDD (ORMs are also bad), but you can also consider SQL as DDD (declarative queries are a way of dealing with only domain logic), and so is the generic serialization problem (so you can use gRPC or JSON, let's say). Note that DDD is NOT creating DSLs -- I'm pretty against DSLs for most things because usually the problem space expands for super general DSLs. People tend to go overboard with DDD though. So much so that there are some people who have snapped back the other way and think that basically nothing should be generic.
- tomnipotent 5y ago
  > ORMs are DDD (ORMs are also bad), but you can also consider SQL as DDD I'm not convinced we're all talking about the same DDD, because ORMs or SQL are not DDD in any context other than being implementation details on a project (unless your domain is specifically providing an ORM or SQL product).
  - hardwaresofton 5y ago
    Well it depends on how you look at it. So ORMs definitely are, just look at the definition and that's exactly what ORMs (with class mappers) usually let you do. Thinking in terms of User instead of DatabaseRow<T> is certainly DDD. What I was wrong about was that SQL isn't really DDD. I didn't realize the colloquial definition[0] is so strict as to call out classes. [0]: https://en.wikipedia.org/wiki/Domain-driven_design https://en.wikipedia.org/wiki/Domain-driven_design
    - aszen 5y ago
      ORMs have nothing to do with DDD, they merely provide objects which map to your database tables. The crux of DDD is to model your application in a domain centric way, what that means is using domain concepts in your business objects instead of just getters and setters. One of the most important things is separating your domain from infrastructure and the ui around it. This can be achieved in a variety of ways, with and without an orm. DDD encourages application designers to start with the domain first, and build the infrastructure and ui around it later on. It changes the language we speak of during designing application, instead of asking whether to use SQL or NoSQL say, you design your domain first + the operations around it and afterwards think about what's the ideal infrastructure to use.
_Understated_ 5y ago
> Think of any baller software project you use. Is it VS Code? Chrome? GitHub? NGINX? Do any of these use DDD? That's a fantastic question. Something I've often wondered too. I'm a fan of DDD but it's like saying "I'm a fan of hammers"... hammers have their place and there is no other tool like them... for the thing they are good at. I used to be all "omg <FoM> is the only way to do things" but nowadays, I tend not to get too hung up on prescribed, named processes and aim for decoupling where it makes sense (for the most part!)
- arethuza 5y ago
  Speaking of hammers and software design reminds me of a classic: https://web.archive.org/web/20180924092925/http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 https://web.archive.org/web/20180924092925/http://discuss.jo... "Nobody really buys hammers anymore. They're kind of old fashioned."
robjan 5y ago
> Chrome? GitHub? NGINX? Do any of these use DDD? These are not business applications, they are general purpose software. A business application is something made to model a business process or an entire business, such as an ERP. DDD is perfect for this.
- Thaxll 5y ago
  Any software can be described as a business application, for Chrome it could be that I want a software that's able to browse and render web pages.
  - deleted 5y ago
    [deleted]

hardwaresofton 5y ago

So I'm not really sure what DDD looks like in those kind of orgs at this point -- DDD is purely a code organization thing -- it's an implementation detail, so I'm not sure how it would show up in a product/dev discussion scenario... The fact that a prodcut team doesn't know what it wants to solve has nothing to do with DDD, other than maybe asking the devs to make the solution as generic as possible (?) -- but that's a bad situation whether you're using DDD or not. I probably just can't understand this because I haven't had this experience

lostcolony 5y ago
That's fair, but I will point out that that's a bit of a "no true scotsman" argument, if it's meant as an argument. Regardless, I'm not really saying anything about DDD; just my experience of organizations saying they're using it. They may indeed be misusing it. They probably are, in fact; my whole point is that the orgs I've encountered that have figured out how to write software successfully don't say they use DDD (even if implicitly they do based on someone's definition of what DDD is), and the orgs I've encountered that say they use DDD to write software then execute very, very poorly, if at all, to the point I don't want to work for orgs that say they use DDD. I believe the cause of that experience to be that the orgs that have cultures that prioritize the right things to where product and dev align very rarely look to adopt new processes that purport to solve problems they already have solved, and the orgs that have cultures that create obstacles look to processes as silver bullets to address them. It's very likely akin to your comment about design patterns; a well built implementation may exhibit some design patterns, even without the author knowing that's what they are. A badly built implementation may look like someone had their gof4 book at hand and was looking for any possible excuse to use a pattern (and they're all named according, FooFactory, BarSingleton, so you can go "yep, they're using design patterns alright"). The latter isn't a judgement on design patterns, but the former may not find very much use for designating what is working for them as design patterns. I.e., it's not necessarily about what is actually in use, but what is being said is in use. My experience is that orgs that say they use DDD = avoid.
lostcolony 5y ago
Also, for how DDD would incorporate both dev and product, product (ostensibly) knows the domain, and needs to communicate it to dev to be able to design things. A logical follow-up, then, is Event Storming ( https://en.wikipedia.org/wiki/Event_storming https://en.wikipedia.org/wiki/Event_storming ) which came out of DDD, and explicitly lists out dev and domain experts as being involved. Which very much points at my earlier comment of trying to solve by process what should be natural from culture (i.e., are dev and product talking to each other).

deleted 5y ago

[deleted]

jacobmoe 5y ago

> all the useful artifacts from it happened naturally because product and dev were so closely aligned. Aren't you just saying that DDD wasn't proposed as a solution to the problem because the problem didn't exist? Starting to jog is a smell that you're out of shape, if you were in shape you wouldn't need to start jogging. One of the ideas that DDD pushes is that product and dev should be closely aligned. The reason that's emphasized is that it isn't the case in a lot of organizations. Of course you could try to avoid all orgs with these kinds of problems (I haven't been able to, unfortunately), but the question is, if encountering an org that _does_ have problems, what solution would you propose?

lostcolony 5y ago
I am indeed saying DDD wasn't proposed as a solution to the problem because the problem didn't exist. I even call that out in the post you're responding to - "Every place I've encountered it, it was attempting to fix with process something that needed to be fixed with culture." And then expound how places with the right culture didn't see value in DDD, and places with poor culture tried to band-aid over it with DDD. As I comment elsewhere, that's not an indictment of DDD as a practice, just that when orgs seek to adopt it it's indicative of a problem, one that DDD won't fix. >>> Starting to jog is a smell that you're out of shape, if you were in shape you wouldn't need to start jogging. Let me rephrase that, since it's not 'starting to jog', but 'jogging'. Trying DDD (because of purported benefits) is different than continuing to use DDD (because of actualized benefits). So "jogging is a smell that you're out of shape; if you're in shape you won't be jogging". And that's patently false. What I think you're trying to say is that jogging will help keep in shape people in shape, and will help out of shape people get into shape as well, yes? Which would equate to "DDD can help effective software orgs stay effective, and ineffective software orgs become effective". Which is a reasonable claim, but one I've simply not seen; I've not encountered an effective software org that used it, and all the ones I've encountered that used it were ineffective, and, at least during my tenure there, remained so. >>> One of the ideas that DDD pushes is that product and dev should be closely aligned. It may try to push that idea, but it does nothing to help it occur. It's implicit, but no more than anything else software related (in that to build something the builders have to know what to build). Certainly, if you asked anyone, using any process, whether or not it's a good idea to have product and dev -unaligned-, they would say "of course not! As a practitioner of X I certainly believe they should be aligned".