3 ms·

So domain modeling has no place in software? The burden of proof for such a claim is a bit higher than "you can't add code to ducks". That ducks are physical i

by gruseom 15y ago

So domain modeling has no place in software? The burden of proof for such a claim is a bit higher than "you can't add code to ducks". That ducks are physical is irrelevant in any case. You can't add code to bank accounts or insurance policies or leap years either.

jerf 15y ago
"You can't add code to payrolls or insurance policies or bank accounts either." No... you can't. Exactly. OO isn't about real-world-objects, it's still about code-objects, and mixing the two up causes serious category errors. Physical modeling is the wrong way to do it, it's the wrong way to teach it, it's the wrong way to conceptualize it, it should not be used in tutorials. Domain modeling != physical modeling, and conflating the two is exactly the problem being addressed. You know you're doing physical modeling when you have a need for an iterator class, but you don't think you can use it, because what on earth is an "iterator"? You can't hold one of those in your hand. The map is not the territory!
- gruseom 15y ago
  I don't get what you're saying. What does it matter whether software is modeling a physical system or, say, a business one? Either way you're drawing on concepts from some domain that exists prior to the software you're building. Either way you're trying to find representations of those concepts suitable for computing what you need to compute. The art of domain modeling is making those representations intelligible in domain terms. This has nothing to do with physicality. Of Evans' canonical examples in Domain Driven Design, one has to do with paint-mixing and another with accounting. The techniques are no different.
  - jerf 15y ago
    "The art of domain modeling is making those representations intelligible in domain terms. This has nothing to do with physicality." Yes, exactly. I do love how often people cite back my own points at me as if they are disagreeing. I think perhaps people have forgotten the origins of OO. A lot of people were taught that the right way to do OO is to match the physical model of the domain they are trying to program for. It's great that you and so many other people have either thoroughly internalized how untrue that is, or were never taught that model in the first place. But I for one was, as were a great deal of the rest of my generation who learned about OO in the 90s, and it's actually somewhat important that we finish stomping the idea out that physical mapping is at all an important aspect of OO. And the best place to stomp it out of is in the Standard OO Tutorial (TM). If you and all the excited downmodders never learned that bad idea in the first place, great! Count yourselves amongst the lucky people who probably also never had to be broken of things like line numbering, or two-letter variable names. (If you think I'm joking, I only wish I could show you some of the first-C++-class homework I graded back in 2000. I'm not joking.) In the meantime, this is a real thing that is still floating around in real curricula today, and you may join me in boggling at this fact, but it doesn't change its truth. It actually stuns me that some of employees that we've hired who graduated as recently as last year appear to have received the exact same OO education that I did in 1999, which was already pretty creaky then. The map is not the territory.
    - gruseom 15y ago
      "I do love how often people cite back my own points at me as if they are disagreeing." For what it's worth, when I read that I found it unpleasant in more ways than one and it killed my interest in further discussion. Perhaps that was for the best, as I didn't seem to be making any progress in understanding you.

by gruseom 15y ago

jerf 15y ago

"You can't add code to payrolls or insurance policies or bank accounts either." No... you can't. Exactly. OO isn't about real-world-objects, it's still about code-objects, and mixing the two up causes serious category errors. Physical modeling is the wrong way to do it, it's the wrong way to teach it, it's the wrong way to conceptualize it, it should not be used in tutorials. Domain modeling != physical modeling, and conflating the two is exactly the problem being addressed. You know you're doing physical modeling when you have a need for an iterator class, but you don't think you can use it, because what on earth is an "iterator"? You can't hold one of those in your hand. The map is not the territory!

gruseom 15y ago
I don't get what you're saying. What does it matter whether software is modeling a physical system or, say, a business one? Either way you're drawing on concepts from some domain that exists prior to the software you're building. Either way you're trying to find representations of those concepts suitable for computing what you need to compute. The art of domain modeling is making those representations intelligible in domain terms. This has nothing to do with physicality. Of Evans' canonical examples in Domain Driven Design, one has to do with paint-mixing and another with accounting. The techniques are no different.
- jerf 15y ago
  "The art of domain modeling is making those representations intelligible in domain terms. This has nothing to do with physicality." Yes, exactly. I do love how often people cite back my own points at me as if they are disagreeing. I think perhaps people have forgotten the origins of OO. A lot of people were taught that the right way to do OO is to match the physical model of the domain they are trying to program for. It's great that you and so many other people have either thoroughly internalized how untrue that is, or were never taught that model in the first place. But I for one was, as were a great deal of the rest of my generation who learned about OO in the 90s, and it's actually somewhat important that we finish stomping the idea out that physical mapping is at all an important aspect of OO. And the best place to stomp it out of is in the Standard OO Tutorial (TM). If you and all the excited downmodders never learned that bad idea in the first place, great! Count yourselves amongst the lucky people who probably also never had to be broken of things like line numbering, or two-letter variable names. (If you think I'm joking, I only wish I could show you some of the first-C++-class homework I graded back in 2000. I'm not joking.) In the meantime, this is a real thing that is still floating around in real curricula today, and you may join me in boggling at this fact, but it doesn't change its truth. It actually stuns me that some of employees that we've hired who graduated as recently as last year appear to have received the exact same OO education that I did in 1999, which was already pretty creaky then. The map is not the territory.
  - gruseom 15y ago
    "I do love how often people cite back my own points at me as if they are disagreeing." For what it's worth, when I read that I found it unpleasant in more ways than one and it killed my interest in further discussion. Perhaps that was for the best, as I didn't seem to be making any progress in understanding you.