4 ms·

> 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 DD

> 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.

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.