When an module becomes too large, you have two primary options for splitting it:What is the best approache?
Splitting the module within the same application.
Splitting it into a separate application
Hi @YO KO ,
Each approach has its own outcome and addresses a specific problem. For example, if we have a core service layer that is too coarse-grained (meaning it combines multiple business areas inside one module), then in that case we should split the module into two or more modules within the same application to improve readability and maintainability.
However, if we have an end-user application that contains this core layer, and another end-user application also needs to consume it (creating side reference between end user apps which is not acceptable) , then the better option is to separate the core layer into its own application (a dedicated Core Layer app). This way, the core functionality can be shared across multiple apps without breaking the architecture.
So we can't say there is a better approach each has its own use.
Depends on the context : Split and keep within the app if all functionality is part of same solution, so its easy to manage and deployments. but still tightly coupled
Move to other app : when functionality could be used by other apps. you achieve better isolation , reusability and independent deployment - app to app dependency may increase management overhead
Adding to Jamal’s answer, I’m sharing a few trainings and articles that could be useful: