Hey Scott, interesting take and definitley one we made the conscious decision to move away from.
By having your project split into their own modules definitley makes moving parts into packages and eventually into a micro-service architecture easier. However, your domain (the problem you are trying to solve) becomes coupled to the wider module. The domain shouldn't care for anything other than the logic for solving the problem and suddenly our domain gets muddied with controllers, dtos and repositories, when in fact our domain module should be concerned with solving problems.
As the domain is the problem solving element of the code, it is the most important part of the code-base and it is vital to keep that as "pure" as possible. As mentioned in the post, ideally, you should be able to lift the domain from the code and nothing extra should come with it.
I also have no plans to move any of my code into a micro service architecture :) But that is personal preference.
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.
Hey Scott, interesting take and definitley one we made the conscious decision to move away from.
By having your project split into their own modules definitley makes moving parts into packages and eventually into a micro-service architecture easier. However, your domain (the problem you are trying to solve) becomes coupled to the wider module. The domain shouldn't care for anything other than the logic for solving the problem and suddenly our domain gets muddied with controllers, dtos and repositories, when in fact our domain module should be concerned with solving problems.
As the domain is the problem solving element of the code, it is the most important part of the code-base and it is vital to keep that as "pure" as possible. As mentioned in the post, ideally, you should be able to lift the domain from the code and nothing extra should come with it.
I also have no plans to move any of my code into a micro service architecture :) But that is personal preference.
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