5 ms·

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'r

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]

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]