4 ms·

> Imagine I have a chicken and an egg. Chicken goes in the animal package and egg goes in the food package. It is now fundamentally impossible to make a chicken

by 9rx 2y ago

> Imagine I have a chicken and an egg. Chicken goes in the animal package and egg goes in the food package. It is now fundamentally impossible to make a chicken lay an egg and an egg hatch a chicken at the same time. I am familiar with people eating unfertilized eggs. I am even familiar with balut. But I am not familiar with the delicacy of eating an egg as it hatches. If you eat an egg as it hatches, wouldn't that actually be eating a chick (the chicken) rather than an egg? I suspect the real problem here is that your domain model is ill-conceived. In fact, while Go has no lack of faults, I suspect the vast majority of the complaints directed towards it come down to the limited feature set not enabling papering over bad design decisions.

fullstackchris 2y ago
I've been writing Go for about 5 years now and can confirm cicular dependency issues were typically handled buy a small refactor or considering where the borders of the domain should _really_ be
- ablob 2y ago
  I think the issue the OC was hinting at is that the borders of the domain are forced to be the files. Having a folder for "food" and a folder for "animal" should not imply that they are in different packages by the OC's reasoning. Perhaps both of them should be the same package, but to achieve this, you can't organise it into folders. _This_ is what OC was complaining about. Considering where the borders of the domain should be is a second handed issue that is only due to the bad choice of having packages be determined by folder structure, which is the complaint of OC.
  - ninetyninenine 2y ago
    Right. And people conflate the issue. Especially go developers. They can’t see the difference. They naturally create folders based off of semantic meaning instead of packaging. Then they hit the dependency issue and they think creating the folder was a domain modeling problem when really they just created the folder based off of semantic meaning and not dependencies. The whole thing has confused go developers. They think putting things into the right folders actually has some deeper design meaning when really it’s just to make it easier for humans to find shit.
ninetyninenine 2y ago
Your joking. I have a hundred food items and a hundred animal items. Cows produce milk. Chickens produce eggs. Eggs produce chickens. It makes 100 percent sense to make two folders. Food and animals. ‘I suspect your “domain model” is ill conceived’??? You buy into that? Don’t follow what those idiots tell you. You realize that we use these actual separations between food and animals in the real world? And now because of some design philosophy the domain model is ill conceived? The result is a more convoluted domain model to make things flow. Actually I think this is an easier way to explain it to you. The “domain model” or aka categorization of food and animals works in reality and every other language because it’s not a bad design decision. The reason why it doesn’t work in go is because go is the bad design decision.
- 9rx 2y ago
  > You realize that we use these actual separations between food and animals in the real world? The distinction between "animal" and "food" isn't necessarily faulty, but an egg considered to be for food and an egg considered to be for hatching are deemed distinct types in the real world. An egg from the grocery store is not going to hatch no matter how hard you coddle it. This is not the same type of egg that will hatch a chicken. Reusing the same model for both types of eggs does not work in the real world, and thus it stands to reason that it doesn't work in software either. Revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear.
  - ninetyninenine 2y ago
    Who said it has to be a grocery store. I’m in a farm. Some eggs I eat, some eggs I hatch. I have a food bin and an animal pen. Two different boxes for two different things. Makes sense in the real world. Why doesn’t it make sense in go? You literally think there’s some elegant underlying principle here having to do with categorization do you? It’s mind boggling to me how arbitrary decisions made by the designers of go are thought of as fundamental design rules. When people use the word “domain model” I know the complex nomenclature has actually led them astray. These are just folders and categories. The term domain model doesn’t change a thing other than making it sound smarter.

by 9rx 2y ago

fullstackchris 2y ago

I've been writing Go for about 5 years now and can confirm cicular dependency issues were typically handled buy a small refactor or considering where the borders of the domain should _really_ be

ablob 2y ago
I think the issue the OC was hinting at is that the borders of the domain are forced to be the files. Having a folder for "food" and a folder for "animal" should not imply that they are in different packages by the OC's reasoning. Perhaps both of them should be the same package, but to achieve this, you can't organise it into folders. _This_ is what OC was complaining about. Considering where the borders of the domain should be is a second handed issue that is only due to the bad choice of having packages be determined by folder structure, which is the complaint of OC.
- ninetyninenine 2y ago
  Right. And people conflate the issue. Especially go developers. They can’t see the difference. They naturally create folders based off of semantic meaning instead of packaging. Then they hit the dependency issue and they think creating the folder was a domain modeling problem when really they just created the folder based off of semantic meaning and not dependencies. The whole thing has confused go developers. They think putting things into the right folders actually has some deeper design meaning when really it’s just to make it easier for humans to find shit.

ninetyninenine 2y ago

Your joking. I have a hundred food items and a hundred animal items. Cows produce milk. Chickens produce eggs. Eggs produce chickens. It makes 100 percent sense to make two folders. Food and animals. ‘I suspect your “domain model” is ill conceived’??? You buy into that? Don’t follow what those idiots tell you. You realize that we use these actual separations between food and animals in the real world? And now because of some design philosophy the domain model is ill conceived? The result is a more convoluted domain model to make things flow. Actually I think this is an easier way to explain it to you. The “domain model” or aka categorization of food and animals works in reality and every other language because it’s not a bad design decision. The reason why it doesn’t work in go is because go is the bad design decision.

9rx 2y ago
> You realize that we use these actual separations between food and animals in the real world? The distinction between "animal" and "food" isn't necessarily faulty, but an egg considered to be for food and an egg considered to be for hatching are deemed distinct types in the real world. An egg from the grocery store is not going to hatch no matter how hard you coddle it. This is not the same type of egg that will hatch a chicken. Reusing the same model for both types of eggs does not work in the real world, and thus it stands to reason that it doesn't work in software either. Revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear.
- ninetyninenine 2y ago
  Who said it has to be a grocery store. I’m in a farm. Some eggs I eat, some eggs I hatch. I have a food bin and an animal pen. Two different boxes for two different things. Makes sense in the real world. Why doesn’t it make sense in go? You literally think there’s some elegant underlying principle here having to do with categorization do you? It’s mind boggling to me how arbitrary decisions made by the designers of go are thought of as fundamental design rules. When people use the word “domain model” I know the complex nomenclature has actually led them astray. These are just folders and categories. The term domain model doesn’t change a thing other than making it sound smarter.