Just a hobbyist programmer with an eye on new technologies. Currently helping Quasar and NestJS Frameworks, because....well.....because they're awesome! :-)
I guess we'll have to agree to sort of disagree. But, I'll leave you with a couple more thoughts.
You are right about the business logic being specific to solve the business problem and it needing its specific place in code. And modules allow for that. Yet, I feel it can't also mean the "plumbing" of the "how the code works" should also be forgotten or changed in a way just to make this "put the business logic in it's own special place" concept possible. If the dev team realize that there is this plumbing around the module, where is that "muddying up the domain"? In fact, if the plumbing also needs work, because the domain problem changes, which I think you can agree does happen, all the code is right there in the module together with the business logic and is thus, easier to reason about and change, no searching for matching plumbing code at all.
If you get new engineers who have worked with Nest before, they will understand the "Nest way" at first sight. If you change the code structure away from Nest's default structure, you add cognitive load thus, slowing down their ability to make changes/ maintain the code.
Lastly, if you decide you want to have different programs (not just microservices) and realize some of the code (the modules) are interchangeable (i.e. plugins), the modules system affords this as designed. If you pull the little onions apart to create your own big onion, it is truly the ugly monolith (with all disadvantages) Nest tries its best to avoid.
Scott
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Harry,
I guess we'll have to agree to sort of disagree. But, I'll leave you with a couple more thoughts.
You are right about the business logic being specific to solve the business problem and it needing its specific place in code. And modules allow for that. Yet, I feel it can't also mean the "plumbing" of the "how the code works" should also be forgotten or changed in a way just to make this "put the business logic in it's own special place" concept possible. If the dev team realize that there is this plumbing around the module, where is that "muddying up the domain"? In fact, if the plumbing also needs work, because the domain problem changes, which I think you can agree does happen, all the code is right there in the module together with the business logic and is thus, easier to reason about and change, no searching for matching plumbing code at all.
If you get new engineers who have worked with Nest before, they will understand the "Nest way" at first sight. If you change the code structure away from Nest's default structure, you add cognitive load thus, slowing down their ability to make changes/ maintain the code.
Lastly, if you decide you want to have different programs (not just microservices) and realize some of the code (the modules) are interchangeable (i.e. plugins), the modules system affords this as designed. If you pull the little onions apart to create your own big onion, it is truly the ugly monolith (with all disadvantages) Nest tries its best to avoid.
Scott