5 ms·

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 bl

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.
    - hardwaresofton 5y ago
      https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks https://en.wikipedia.org/wiki/Domain-driven_design#Building_...
  - tomnipotent 5y ago
    I don't think you have a grasp on what DDD is or confusing it with more concrete architectural or design patterns. An ORM has nothing to do with Domain-Driven Design, nor bounded contexts or aggregate roots or events or the many other parts that are DDD.
    - hardwaresofton 5y ago
      Again, I really think we're having some fundamental disagreements about what "DDD" is. Maybe that term is just doomed and what I'll say from now on is "hexagonal infrastructure". For now, this is where I'm drawing my definition (that I use in this thread) of what DDD is, and what makes me think ORMs are indeed DDD: https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks https://en.wikipedia.org/wiki/Domain-driven_design#Building_...
      - dragonwriter 5y ago
        > For now, this is where I'm drawing my definition (that I use in this thread) of what DDD is, and what makes me think ORMs are indeed DDD That doesn’t mention ORMs at all, and I’m not sure what in that source gave you the idea. ORM had no fundamental connection to DDD; an ORM could be used in the implementation of Repositories, but there is no strong link between the ideas.
        camgunz 5y ago
        I said this up a little further but, I think there's realistically no way to avoid an ORM when implementing DDD in an OO language, using an SQL database. Like, like it or not, DDD's wheelhouse was going into Java shops and telling them how to structure their apps. Those shops use objects and they almost certainly (though not absolutely certainly) use a relational database. You're not gonna get away from mapping your relational data to your objects, the only choice you have is to use an off the shelf ORM, or to build your own. So I think that's mostly inarguable. I do think building an app on a document database is interesting though, because then there's no need for the "mapping", so to speak (depending on how static/dynamic your OO language is), but I don't necessarily see how that fact means that ORMs aren't DDD. But broadly, the case I'm referring to is: - We wanted to implement DDD - We were using Django, i.e. QuerySets and Models - We wrapped QuerySets to make "repositories" - We wrapped Models to make "entities" - This was silly (read: more confusing, slower, and a waste of engineering resources), because QuerySets and Models are already DDD, because ORMs are DDD
- camgunz 5y ago
  I don't think saying ORMs are an implementation detail is useful. DDD is a design and implementation strategy. It is telling you how to structure and build your application. For example, DDD says you should have entities and repositories. Well, that's an ORM: you have models (entities) and some kind of querying facility (maybe a fluent API, maybe a parameterized API, but whatever, it's a repo). Realistically, when using an OO language w/ an SQL database, there's realistically no other way to do this. You'll either use an existing ORM, or you'll end up building a weird, custom ORM. In fact, some of my frustration with DDD is that because it uses so much new language to refer to existing concepts, techniques, and technologies, it obfuscates the fact that you're probably already using DDD in some significant measure. Like are you using Spring, Rails, or Django? You're probably more than 3/4 the way to DDD.
camgunz 5y ago
Oh that's pretty insightful about SQL, innnnteresting. Yeah stuff like this gets entwined with engineers' experiences, so you get very subjective takes. Plus, there seems to be some kind of human bug with these things that gets people fanatic about them (see also Agile, DRY, microservices) that then creates a lot of backlash. Like, it'll be hard for anyone to get me to do DDD ever again, just because my intro to it was pretty negative, and no matter how pragmatic or whatever I was in trying to analyze our performance after, our CTO was like "nah we're doing it, please be quiet". I don't know about you but, that doesn't sound like engineering to me. But that aside, I find that I generally agree w/ DDD. I like coming up with the language of the domain, I like the idea of event storming, I like immutable values, etc. I generally think it maps well to modern web apps, and FWIW people seem to agree, see GraphQL, Redux, and so on. I always come back to construction--there's building and there's building science. When you're building, do things you know work, don't experiment. But in-between or on side projects, try out new things building science has invented, tested, and the industry has productized. If someone came to me and said, "use this ___", I'd say "show me stats, metrics, case studies, examples, comparisons", and then if all that went well, we might start evaluation--on the way to evolving our process. Doing anything else feels like satisfying a different need, maybe that need is important, but it's not the same need as "build things professionally".
- hardwaresofton 5y ago
  > Oh that's pretty insightful about SQL, innnnteresting. Probably a little wrong but interesting food for thought nonetheless. > Yeah stuff like this gets entwined with engineers' experiences, so you get very subjective takes. Plus, there seems to be some kind of human bug with these things that gets people fanatic about them (see also Agile, DRY, microservices) that then creates a lot of backlash. Like, it'll be hard for anyone to get me to do DDD ever again, just because my intro to it was pretty negative, and no matter how pragmatic or whatever I was in trying to analyze our performance after, our CTO was like "nah we're doing it, please be quiet". I don't know about you but, that doesn't sound like engineering to me. Well that sounds like a bad atmosphere, but also the people side of things is REALLY hard at work (or in life in general). When someone with authority has an idea and they want to do it, it's probably going to happen and standing in the way of it doesn't do any good most of the time. Sometimes it's even worse and then becomes a personal vendetta thing where they just start perceiving you as a threat to their dominance. > But that aside, I find that I generally agree w/ DDD. I like coming up with the language of the domain, I like the idea of event storming, I like immutable values, etc. I generally think it maps well to modern web apps, and FWIW people seem to agree, see GraphQL, Redux, and so on. Yup, I agree -- it's overkill for most apps because the DDD's been done for you most of the time at this point (there was a time where it wasn't), but the DDD promised land is really enticing to me. > I always come back to construction--there's building and there's building science. When you're building, do things you know work, don't experiment. But in-between or on side projects, try out new things building science has invented, tested, and the industry has productized. If someone came to me and said, "use this ___", I'd say "show me stats, metrics, case studies, examples, comparisons", and then if all that went well, we might start evaluation--on the way to evolving our process. Doing anything else feels like satisfying a different need, maybe that need is important, but it's not the same need as "build things professionally". Fully agreed... In particular > how me stats, metrics, case studies, examples, comparisons This is basically how I judge F/OSS projects and/or new tooling I might use. If you find a project and it has a comparison to it's competitors/alternatives in the README (and clear screenshots/usecase/examples), then I'm almost always sold (then I go check the issues and look at open/closed ratio, whether they use an autoclose bot, etc). Since I can't see a world where the VC dollars stop flowing, I don't know if we'll ever be at a point where building things professionally (like... in the engineering sense) will ever become mainstream. Even if you waste 90% of a developer's salary, if that developer contributes something that increases revenue by 1%, you usually gain WAY MORE than the developer was worth as the business owner (in perpetuity as well, all other things equal). It's just not cost-effective to engineer well upfront sometimes (see RethinkDB and MongoDB), though I still strive for that.

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.
  - hardwaresofton 5y ago
    https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks https://en.wikipedia.org/wiki/Domain-driven_design#Building_...
- tomnipotent 5y ago
  I don't think you have a grasp on what DDD is or confusing it with more concrete architectural or design patterns. An ORM has nothing to do with Domain-Driven Design, nor bounded contexts or aggregate roots or events or the many other parts that are DDD.
  - hardwaresofton 5y ago
    Again, I really think we're having some fundamental disagreements about what "DDD" is. Maybe that term is just doomed and what I'll say from now on is "hexagonal infrastructure". For now, this is where I'm drawing my definition (that I use in this thread) of what DDD is, and what makes me think ORMs are indeed DDD: https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks https://en.wikipedia.org/wiki/Domain-driven_design#Building_...
    - dragonwriter 5y ago
      > For now, this is where I'm drawing my definition (that I use in this thread) of what DDD is, and what makes me think ORMs are indeed DDD That doesn’t mention ORMs at all, and I’m not sure what in that source gave you the idea. ORM had no fundamental connection to DDD; an ORM could be used in the implementation of Repositories, but there is no strong link between the ideas.
      - camgunz 5y ago
        I said this up a little further but, I think there's realistically no way to avoid an ORM when implementing DDD in an OO language, using an SQL database. Like, like it or not, DDD's wheelhouse was going into Java shops and telling them how to structure their apps. Those shops use objects and they almost certainly (though not absolutely certainly) use a relational database. You're not gonna get away from mapping your relational data to your objects, the only choice you have is to use an off the shelf ORM, or to build your own. So I think that's mostly inarguable. I do think building an app on a document database is interesting though, because then there's no need for the "mapping", so to speak (depending on how static/dynamic your OO language is), but I don't necessarily see how that fact means that ORMs aren't DDD. But broadly, the case I'm referring to is: - We wanted to implement DDD - We were using Django, i.e. QuerySets and Models - We wrapped QuerySets to make "repositories" - We wrapped Models to make "entities" - This was silly (read: more confusing, slower, and a waste of engineering resources), because QuerySets and Models are already DDD, because ORMs are DDD
camgunz 5y ago
I don't think saying ORMs are an implementation detail is useful. DDD is a design and implementation strategy. It is telling you how to structure and build your application. For example, DDD says you should have entities and repositories. Well, that's an ORM: you have models (entities) and some kind of querying facility (maybe a fluent API, maybe a parameterized API, but whatever, it's a repo). Realistically, when using an OO language w/ an SQL database, there's realistically no other way to do this. You'll either use an existing ORM, or you'll end up building a weird, custom ORM. In fact, some of my frustration with DDD is that because it uses so much new language to refer to existing concepts, techniques, and technologies, it obfuscates the fact that you're probably already using DDD in some significant measure. Like are you using Spring, Rails, or Django? You're probably more than 3/4 the way to DDD.

camgunz 5y ago

Oh that's pretty insightful about SQL, innnnteresting. Yeah stuff like this gets entwined with engineers' experiences, so you get very subjective takes. Plus, there seems to be some kind of human bug with these things that gets people fanatic about them (see also Agile, DRY, microservices) that then creates a lot of backlash. Like, it'll be hard for anyone to get me to do DDD ever again, just because my intro to it was pretty negative, and no matter how pragmatic or whatever I was in trying to analyze our performance after, our CTO was like "nah we're doing it, please be quiet". I don't know about you but, that doesn't sound like engineering to me. But that aside, I find that I generally agree w/ DDD. I like coming up with the language of the domain, I like the idea of event storming, I like immutable values, etc. I generally think it maps well to modern web apps, and FWIW people seem to agree, see GraphQL, Redux, and so on. I always come back to construction--there's building and there's building science. When you're building, do things you know work, don't experiment. But in-between or on side projects, try out new things building science has invented, tested, and the industry has productized. If someone came to me and said, "use this ___", I'd say "show me stats, metrics, case studies, examples, comparisons", and then if all that went well, we might start evaluation--on the way to evolving our process. Doing anything else feels like satisfying a different need, maybe that need is important, but it's not the same need as "build things professionally".

hardwaresofton 5y ago
> Oh that's pretty insightful about SQL, innnnteresting. Probably a little wrong but interesting food for thought nonetheless. > Yeah stuff like this gets entwined with engineers' experiences, so you get very subjective takes. Plus, there seems to be some kind of human bug with these things that gets people fanatic about them (see also Agile, DRY, microservices) that then creates a lot of backlash. Like, it'll be hard for anyone to get me to do DDD ever again, just because my intro to it was pretty negative, and no matter how pragmatic or whatever I was in trying to analyze our performance after, our CTO was like "nah we're doing it, please be quiet". I don't know about you but, that doesn't sound like engineering to me. Well that sounds like a bad atmosphere, but also the people side of things is REALLY hard at work (or in life in general). When someone with authority has an idea and they want to do it, it's probably going to happen and standing in the way of it doesn't do any good most of the time. Sometimes it's even worse and then becomes a personal vendetta thing where they just start perceiving you as a threat to their dominance. > But that aside, I find that I generally agree w/ DDD. I like coming up with the language of the domain, I like the idea of event storming, I like immutable values, etc. I generally think it maps well to modern web apps, and FWIW people seem to agree, see GraphQL, Redux, and so on. Yup, I agree -- it's overkill for most apps because the DDD's been done for you most of the time at this point (there was a time where it wasn't), but the DDD promised land is really enticing to me. > I always come back to construction--there's building and there's building science. When you're building, do things you know work, don't experiment. But in-between or on side projects, try out new things building science has invented, tested, and the industry has productized. If someone came to me and said, "use this ___", I'd say "show me stats, metrics, case studies, examples, comparisons", and then if all that went well, we might start evaluation--on the way to evolving our process. Doing anything else feels like satisfying a different need, maybe that need is important, but it's not the same need as "build things professionally". Fully agreed... In particular > how me stats, metrics, case studies, examples, comparisons This is basically how I judge F/OSS projects and/or new tooling I might use. If you find a project and it has a comparison to it's competitors/alternatives in the README (and clear screenshots/usecase/examples), then I'm almost always sold (then I go check the issues and look at open/closed ratio, whether they use an autoclose bot, etc). Since I can't see a world where the VC dollars stop flowing, I don't know if we'll ever be at a point where building things professionally (like... in the engineering sense) will ever become mainstream. Even if you waste 90% of a developer's salary, if that developer contributes something that increases revenue by 1%, you usually gain WAY MORE than the developer was worth as the business owner (in perpetuity as well, all other things equal). It's just not cost-effective to engineer well upfront sometimes (see RethinkDB and MongoDB), though I still strive for that.