4 ms·

What I've noticed over the years is that software engineers tend to sometimes mistakenly believe that when they are, for example, modeling some domain that they

What I've noticed over the years is that software engineers tend to sometimes mistakenly believe that when they are, for example, modeling some domain that they are involved in some sort of Aristotelian categorization exercise wherein they are trying to capture the true essence of some pure Platonic form. In reality, whenever anything comes under the umbrella of software, we are doing it not because we are interested in some ontological sense of the thing under consideration, but because it has some usefulness for a particular line of business. This I think is the key thing. There are unifications and abstractions that make sense in a pure theoretical sense, but that serve no purpose when it comes to software that is meant to serve some practical end.

drekipus 2y ago
This is something that I'm trying to take note of. Thanks for this comment.
epgui 2y ago
You make it sound like understanding the domain is some sort of pontification…
ParetoOptimal 2y ago
There is a balance here. Good domain modeling can enable making illegal states unrepresentable. Sometimes, there needs to be more flexibility because of a lack of understanding. However, other times you can put in a little effort and get the understanding needed for a good data model that simplifies future velocity and correctness a ton.
- temporarely 2y ago
  I think you miss the fine point here. Ontological truth =/= Good domain modeling. OP is not arguing against domain modeling, rather a likely common trap of creating an analog of 'the world' (however delimited) as foundation for the model. I know exactly what they mean because I am guilty as charged. I used to do this all the time in mid career.
  - tilt_error 2y ago
    Yes, you shouldn't "boil the ocean".
    - kybernetikos 2y ago
      You should usually also not "model the ocean"
campbel 2y ago
Treating features as independent mutations may incrementally improve the software, but this approach can quickly lead to an incoherent codebase that is difficult to modify without introducing regressions. Proper domain modeling is done so we can organize around patterns.
crabmusket 2y ago
This is very important. You can't build software given only knowledge of a domain. You also need requirements. The classic OOP educational example of `class Dog extends Pet` is a case in point. In what sense is a dog like a pet? The only way to know the answer to that is to look at it through the lens of our requirements. Are we building a vet appointment booking app, or a video game? Educational examples can be misleading due to lacking real requirements, and lead programmers to reproduce oversimplified structures.
- crabmusket 2y ago
  I wrote a more fleshed-out example of what I'm talking about on Reddit[1], but to save you the click through I'll reproduce it here: [begin quote] > [OOP] also make you have to think heavly about design, as you'll get yourself thinking about stupid things like "Does a buyer sell the goods, or does the customer buy the goods? What if we’re firing someone? Does a manager fire the person? Does the person fire themself? What if HR initiated the process, not the manager?" This smells like very poor application of OOP. Let's take the firing example, it sounds like you're trying to design code like this: employee1.fire(employee2); But that's almost never what you want to do. Instead of designing classes that map to "things" like employees, it's likely your classes should be modelling business use cases like EmployeeTerminationProcess. To make up a bunch of stuff, let process = EmployeeTerminationProcess.create({ initiator: employee1, toBeFired: employee2, }).begin(); // later, if (process.hasEnoughDocumentationBeenProvided()) { mailer.send(process.makeTerminationEmail()); } // or maybe, if (process.isComplete()) { process.archiveAllMaterials(); } `create` might even be a factory which returns instances of different specialised classes for different processes. Say if the documentation requirements are different when the process is initiated by a manager or by HR. Trying to fit the colloquial English phrase "Bob was fired by Janet" directly into a line of code results in weirdness; instead of modelling English, you should be modelling the business process itself. The problems you have with classes are common, and a result of crappy education and crappy existing codebases. It seems like industry and academia have gone through a wave of "let's model tangible objects as classes" which was never a good idea. With any luck, the rise of functional programming will remind practitioners in OOP languages that abstractions are real (as David Deutsch described it) and that every tutorial containing class Dog extends Animal needs to be put in a bin. [end quote] [1]: https://www.reddit.com/r/node/comments/pyokmi/a_reflection_about_scalable_project_architectures/hexps95/ https://www.reddit.com/r/node/comments/pyokmi/a_reflection_a...

drekipus 2y ago

This is something that I'm trying to take note of. Thanks for this comment.

epgui 2y ago

You make it sound like understanding the domain is some sort of pontification…

ParetoOptimal 2y ago

There is a balance here. Good domain modeling can enable making illegal states unrepresentable. Sometimes, there needs to be more flexibility because of a lack of understanding. However, other times you can put in a little effort and get the understanding needed for a good data model that simplifies future velocity and correctness a ton.

temporarely 2y ago
I think you miss the fine point here. Ontological truth =/= Good domain modeling. OP is not arguing against domain modeling, rather a likely common trap of creating an analog of 'the world' (however delimited) as foundation for the model. I know exactly what they mean because I am guilty as charged. I used to do this all the time in mid career.
- tilt_error 2y ago
  Yes, you shouldn't "boil the ocean".
  - kybernetikos 2y ago
    You should usually also not "model the ocean"

campbel 2y ago

Treating features as independent mutations may incrementally improve the software, but this approach can quickly lead to an incoherent codebase that is difficult to modify without introducing regressions. Proper domain modeling is done so we can organize around patterns.

crabmusket 2y ago

This is very important. You can't build software given only knowledge of a domain. You also need requirements. The classic OOP educational example of `class Dog extends Pet` is a case in point. In what sense is a dog like a pet? The only way to know the answer to that is to look at it through the lens of our requirements. Are we building a vet appointment booking app, or a video game? Educational examples can be misleading due to lacking real requirements, and lead programmers to reproduce oversimplified structures.

crabmusket 2y ago
I wrote a more fleshed-out example of what I'm talking about on Reddit[1], but to save you the click through I'll reproduce it here: [begin quote] > [OOP] also make you have to think heavly about design, as you'll get yourself thinking about stupid things like "Does a buyer sell the goods, or does the customer buy the goods? What if we’re firing someone? Does a manager fire the person? Does the person fire themself? What if HR initiated the process, not the manager?" This smells like very poor application of OOP. Let's take the firing example, it sounds like you're trying to design code like this: employee1.fire(employee2); But that's almost never what you want to do. Instead of designing classes that map to "things" like employees, it's likely your classes should be modelling business use cases like EmployeeTerminationProcess. To make up a bunch of stuff, let process = EmployeeTerminationProcess.create({ initiator: employee1, toBeFired: employee2, }).begin(); // later, if (process.hasEnoughDocumentationBeenProvided()) { mailer.send(process.makeTerminationEmail()); } // or maybe, if (process.isComplete()) { process.archiveAllMaterials(); } `create` might even be a factory which returns instances of different specialised classes for different processes. Say if the documentation requirements are different when the process is initiated by a manager or by HR. Trying to fit the colloquial English phrase "Bob was fired by Janet" directly into a line of code results in weirdness; instead of modelling English, you should be modelling the business process itself. The problems you have with classes are common, and a result of crappy education and crappy existing codebases. It seems like industry and academia have gone through a wave of "let's model tangible objects as classes" which was never a good idea. With any luck, the rise of functional programming will remind practitioners in OOP languages that abstractions are real (as David Deutsch described it) and that every tutorial containing class Dog extends Animal needs to be put in a bin. [end quote] [1]: https://www.reddit.com/r/node/comments/pyokmi/a_reflection_about_scalable_project_architectures/hexps95/ https://www.reddit.com/r/node/comments/pyokmi/a_reflection_a...