Lead for JavaScript e2e DX at Microsoft Azure. ex-Architect at MongoDB. ex-Principal Architect Adobe Stack at Cognizant. GDE for #Angular and #WebTechnologies Opinions my own.
Education
The Internet
Pronouns
she/her
Work
Principal JavaScript e2e DX/Dev Tools Lead @Microsoft Azure
I am not really with energy enough to have a very long discussion on this, and appreciate your opinion, but do not share it at a 100%. Usually all services inherit (or should, from a base) and that base needs a common place to be. Some services are shared between several domains, and they also need a common place to be at. Creating cross domain dependencies is a far worse issue. The principle of proximity admits exceptions. This scenario is valid for a small to medium sized application. For an enterprise application, rewriting the same code snippets over and over to maintain them in proximity, will cause you a real maintenance issue.
Also my impression is that people need to get better at browsing with their IDE's. And I mean by class and by code inside a folder.
We can't always agree, Lars. :D We do on other items though!
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
Interesting, I rarely find the need to use inheritance. I favor composition over inheritance. It's got a much looser coupling.
Classes that are shared between feature or domains can live in libraries or folders inside of a shared grouping folder.
About DRY, I think it's generally being used too much as an excuse without considering it's trade-offs. An abstraction made too early can become very expensive and difficult to undo later in a project's life span.
Lead for JavaScript e2e DX at Microsoft Azure. ex-Architect at MongoDB. ex-Principal Architect Adobe Stack at Cognizant. GDE for #Angular and #WebTechnologies Opinions my own.
Education
The Internet
Pronouns
she/her
Work
Principal JavaScript e2e DX/Dev Tools Lead @Microsoft Azure
I am not really with energy enough to have a very long discussion on this, and appreciate your opinion, but do not share it at a 100%. Usually all services inherit (or should, from a base) and that base needs a common place to be. Some services are shared between several domains, and they also need a common place to be at. Creating cross domain dependencies is a far worse issue. The principle of proximity admits exceptions. This scenario is valid for a small to medium sized application. For an enterprise application, rewriting the same code snippets over and over to maintain them in proximity, will cause you a real maintenance issue.
Also my impression is that people need to get better at browsing with their IDE's. And I mean by class and by code inside a folder.
We can't always agree, Lars. :D We do on other items though!
Interesting, I rarely find the need to use inheritance. I favor composition over inheritance. It's got a much looser coupling.
Classes that are shared between feature or domains can live in libraries or folders inside of a shared grouping folder.
About DRY, I think it's generally being used too much as an excuse without considering it's trade-offs. An abstraction made too early can become very expensive and difficult to undo later in a project's life span.
"Classes that are shared between feature or domains can live in libraries or folders inside of a shared grouping folder."
That was my point.